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INTRODUC  TION 


1.  0 

The  problems  that  the  Department  of  Defense  is  facing  today  in  avionics  can 
be  summarized  in  three  basic  areas:  excessive  cost,  low  reliability  and 
lack  of  standardization. 

The  high  cost  associated  with  the  development,  procurement  and  support  of 
new  weapon  systems  and  the  associated  flow  time  required  to  accomplish  an 
avionics  system  evolution  are  limitations  to  the  approval  of  new  needed 
systems.  In  addition,  the  problems  of  poor  field  reliability  and  the  difficulty 
of  repair  of  existing  avionics  that  was  not  designed  to  a  common  standard 
have  decreased  the  effective  level  of  the  operational  units.  This  lack  of 
standardization  has  fostered  an  environment  in  which  each  new  weapon  system 
can  require  all  new  hardware,  software,  and  support  equipment. 

In  order  to  reverse  this  trend,  avionics  proliferation  and  cost  must  be  re¬ 
duced  while  increasing  avionics  availability.  One  method  of  achieving  this 
goal  is  to  promote  standards  which  provide  avionics  architectural  commonality 
across  systems.  This  is  being  accomplished  to  some  extent  through  MIL,- 
STD-1553B  and  the  DAIS  concept  and  program. 

The  use  of  1553  alone,  however,  does  not  insure  interface  commonality  for 
two  basic  reasons:  (1)  1553  is  not  a  specification  but  a  standard  and  there¬ 
fore  defines  system  requirements  without  dictating  hardware  design  and  (2) 
the  standard  has  undergone  changes  during  its  ten  year  development  which 
has  resulted  in  minor  differences  in  systems  developed  at  different  times 
within  this  period. 

This  study  was  initiated  in  order  to  classify  and  analyze  the  characteristics 
of  a  number  of  existing  multiplex  systems  and  to  devise  methods  of  over¬ 
coming  the  incompatibilities  which  presently  exist. 


1.1  STUDY  OBJECTIVES  AND  APPROACH 

This  section  includes  a  historical  summary  of  the  establishment  of  the 
MIL-STD-1553  multiplex  data  bus  standard  as  well  as  a  statement  of  the  study 
objectives  and  the  general  study  approach  which  was  taken. 

1.  1.  1  MIL-STD-1553  Historical  Summary 

The  development  of  a  standard  digital  time  division  multiplex  data  bus  began 
in  early  1968  with  the  establishment  by  the  Society  of  Automotive  Engineers 
(SAE)  of  a  subcommittee  of  industry  and  military  personnel  to  define  some 
of  the  basic  requirements  of  a  serial  data  bus.  The  subcommittee.  Multiplexing 
for  Aircraft  (SAE-A2K),  developed  the  first  draft  of  a  data  bus  standard 
which  was  similar  to  the  present  military  standard.  It  represented  a  mix¬ 
ture  of  "military  standard"  requirements  and  "procurement  specification" 
requirements.  Its  format  allowed  standardization  on  requirements  that 
could  be  agreed  upon  and  a  slash  sheet  in  the  appendix  for  requirements 
that  appeared  to  be  vehicle  particular.  This  document  represented  the  best 
that  industry  and  the  military  could  define  at  the  time.  The  benefit  of  this 
document  was  that  it  produced  a  sounding  board  for  ideas.  In  this  respect, 
it  was  successful  and  provided  the  step  forward  required  to  develop  the  USAF 
Military  Standard,  MIL-STD-1553,  in  August  1973.  During  the  years  from 
inception  of  the  SAE-A2K  to  the  release  of  the  first  military  documents,  the 
industry  was  designing  and  producing  hardware  for  various  multiplex  sys¬ 
tems.  Some  of  these  systems  were  developed  prior  to  or  during  the  stan¬ 
dardization  era  (e.  g,  ,  F-15  and  B-l).  Because  of  program  timing,  each  of 
these  systems  had  gone  its  own  way  because  no  standardization  effort  existed 
at  the  time:  however,  with  the  production  of  the  F-16,  MIL-STD-1553  (USAF) 
found  its  first  full  aircraft  application.  From  1973  to  1975  (when  MIL-STD- 
1553A  was  released),  industry  and  the  military  (Air  Force,  Army,  and  Navy) 
coordinated  their  efforts  to  determine  the  degree  of  standardization  required. 
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Several  preliminary  drafts  of  Air  Force  and  Navy  documents  were  developed 
and  extensive  industry  comments  were  solicited  during  these  years. 

By  late  1974  and  early  1975  the  DoD  directed  the  military  to  develop  a  single 
position  and  to  make  the  necessary  revisions  to  MIL-STD- 1553(USAF).  Based 
on  this  effort,  1553A  was  released  in  April  1975.  Since  1975,  industry  and 
the  military  have  continued  to  coordinate  the  standard  through  symposia, 
studies  and  military  development  programs.  With  the  standard  available, 
both  industry  and  the  military  began  to  apply  the  data  bus  to  more  operational 
vehicles  and  systems.  As  applications  became  extensive,  certain  difficulties 
were  recognized  in  MIL-STD-  1553A. 

Discussions  concerning  these  difficulties  were  conducted  between  the  SAE 
A2K  and  DoD  Tri-Services  Committee  (the  responsible  group  for  controlling 
the  MIL-STD).  The  results  of  these  discussions  was  the  formation  of  an 
SAE  task  group,  "MIL-STD- 1 553  Update,  "  in  October  1976.  The  task  group's 
assignment  was  to  develop  suggested  changes  to  1553A.  Once  again  a 
task  group  was  formed  from  several  industry  and  military  segments.  The 
task  group  solicited  comments  from  industry  and  the  military  to  support  its 
work.  These  responses  were  extensive  and  involved  foreign  as  well  as 
domestic  equipment  suppliers  and  users  of  the  standard.  It  was  from  this 
base  that  the  task  group  developed  and  presented  the  suggested  revisions 
to  1553A.  In  October  1977,  after  review  and  discussion  of  suggested  changes, 
the  SAE-A2K  approved  a  proposed  revision  and  in  December  1977  these 
recommendations  were  provided  to  the  DoD  Tri-Service  Committee.  In 
addition  to  the  SAE  input,  industry  comments  on  changes  to  1S53A  were 
solicited  in  January  1978  by  the  DoD  Tri-Service  Committee.  Based  on 
these  comments,  the  DoD  Tri-Service  Committee  met  on  several  occasions 
and  produced  a  draft  of  1553B.  This  draft  was  presented  to  the  SAE's  task 
group  in  April  1978,  for  review  and  comment.  Following  this  review,  one 
final  meeting  was  held  with  task  group  members  in  June  1978  during  which 
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final  agreement  between  the  SAE  task  group  and  the  Tri-Service  Committee 
was  obtained.  From  these  verbal  agreements,  a  final  written  approval  was 
sought  within  the  Tri-Service  Committee  and,  upon  receipt  of  the  written 
approvals,  MIL-STD- 1553B  was  released  as  an  official  document  September 
21,  1978. 

As  can  be  imagined  from  the  foregoing  chronology,  any  system  developed 
prior  to  or  during  the  1968-1978  time  period  would  have  at  best,  an  early 
version  of  the  standard  to  work  to  and  at  worst,  no  standard  at  all.  Con¬ 
sequently,  each  airframe  manufacturer  developed  his  own  system  spec¬ 
ification  which  was  based  on  whatever  standard  (released  or  not)  was  available 
at  the  time.  The  result  was  a  series  of  manufacturers  specifications 
based  more  or  less  loosely  on  1553.  Examples  are  MDC  H009  (F-15), 

GD  16PP188  (F - 16),  MDC  A3818  (F-18),  IBM  6226114  (LAMPS),  and  Boeing 
D675- 101 1 0~  1  (B-52  OAS).  In  November  1974,  the  DAIS  Multiplex  Document 
(DAIS-04-03)  was  released.  Although  1553A  was  available  at  this  time,  it 
was  in  the  process  of  revision.  The  DAIS  Document,  therefore,  made  no 
reference  to  the  standard,  as  such,  but  included  most  of  the  requirements. 

As  DAIS  progressed,  it  was  converted  to  1553B  in  early  1980  (refer  to  SA 
321  200). 

1.  1.  2  Study  Objectives 

In  the  light  of  the  above  facts,  it  would  be  highly  desirable  for  future  avionics 
systems  to  have  a  bus  interface  which  (1)  is  compatible  with  all  existing 
MIL-STD-1553  and  similar  data  buses  (downward  compatibility)  and  (2) 
has  sufficient  flexibility  to  interface  with  future  bus  systems  which  may  be 
designed  to  future  revisions  of  1553  or  which  contain  minor  deviations  to  the 
standard  (upward  compatibility). 

The  goal  of  this  study  was  to  determine  the  feasibility  of  such  an  interface 
and  to  define  an  approach  to  its  design  and  implementation. 
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1.  1.  3  Proposed  Study  Approach 

The  approach  to  the  study  was  based  on  extensive  experience  in  meeting  the 
needs  of  a  large  variety  of  multiplex  data  bus  users.  The  development  of 
standard  multiplex  data  bus  products  such  as  the  SCI  MTI-1IG  multiplex 
terminal  unit  required  a  thorough  understanding  of  the  various  require¬ 
ments  of  users  and  potential  users,  both  military  and  commercial,  and  the 
ability  to  incorporate  a  variety  of  desirable  features  and  options  into  a 
single  standard  product. 

The  study  provides  an  assessment  of  the  feasibility  for  definition  of  an 
interface  design  which  will  allow  interconnection  of  avionic  subsystems 
across  a  variety  of  aircraft  multiplex  systems.  The  study  approach  includes 
the  following: 

Task  1  -  Data  Gathering 

Task  2  -  Feasibility  Study 

Task  3  -  Selection  of  Techniques 

Each  of  these  tasks  is  described  in  the  following  section. 


j 


STUDY  TASK  DEFINITIONS 


1.  2 

1.  2.  1  Task  1  -  Data  Gathering 

The  first  task  of  the  study  consists  of  the  collection  and  compilation  of  the 
characteristics  of  a  number  of  aircraft  multiplex  systems.  Although  Air 
Force  aircraft  received  priority,  consideration  was  also  given  to  other 
military  and  commercial  aircraft.  For  example,  the  somewhat  different 
bus  characteristics  of  Navy  aircraft  such  as  the  F-18  (MDC  A3818) 
were  of  particular  interest.  The  data  gathering  phase  was  a  relatively  simple 
task  since  much  of  the  required  data  was  readily  available.  Such  information 
is  routinely  accumulated  in  the  course  of  production  of  data  bus  products 
for  military  aircraft  and  participation  in  industry  forums  such  as  the  SAE- 
A2K  subcommittee  and  the  AFSC  Data  Bus  Conferences.  A  significant 
volume  of  this  data  was  accumulated  during  the  preparation  of  portions  of 
the  Multiplex  Applications  Handbook  which  was  recently  delivered  under 
contract  to  AF/ASD.  This  handbook  was  used  extensively  as  a  reference 
during  the  course  of  the  study. 

1.  2.  2  Task  2  -  Feasibility  Study 

The  second  task  consists  of  the  analysis  of  the  multiplex  system  data 
collected  in  Task  1  to  determine  the  points  cf  incompatibility  between 
candidate  systems.  At  this  point,  a  sizeable  number  of  bus  characteristics 
which  are  common  to  all  systems  were  discarded  and  attention  was  focused 
on  the  remaining  characteristics  which  differ  from  one  system  to  the  next. 
Examples  of  common  characteristics  would  be  the  transmission  cable  and 
coupling  characteristics  which  are  well  defined  by  1553  and  generally 
compatible  across  system  lines.  Various  word  formats  such  as  the  status 
word  format  and  mode  control  codes  are  not  so  well  defined  and  may  be 
expected  to  vary. 


1.  2.  3 


Selection  of  Techniques 

The  results  of  the  feasibility  study  were  used  in  this  task  to  assess  possible 
techniques  to  be  used  in  achieving  bus  compatibility.  It  is  this  task  which 
brings  together  data  accumulated  and  analyzed  during  the  other  tasks  for 
development  of  the  final  goal  of  the  study.  This  task  devises  methods  of 
overcoming  the  incompatibilities  previously  identified.  Methods  considered 
include  the  use  of  microprogrammable  interfaces  to  allow  flexibility  in  word 
formatting  and  protocol.  This  method  is  presently  used  in  a  family  of 
flexible  multiplex  terminal  interfaces  now  in  production  for  various 
minicomputers.  Firmware  and  software  techniques  are  also  to  be 
considered. 

1.  3  RECOMMENDATIONS  AND  SUMMARY 

Performance  of  the  study  as  outlined  above  resulted  in  basic  conclusions 
and  recommendations  in  the  following  major  areas: 

•  ARINC  and  H009  (F-15)  interfaces 

•  Basic  signal  characteristics 

•  1553  vs.  A3818  type  waveform 

•  System-peculiar  mode/  status  codes 

•  Recommended  Programmable  Interface  Module  configuration 

These  conclusions  and  recommendations  are  summarized  briefly  in  this 
section. 


1.3.1  ARINC  and  H009  (F-15)  Interfaces 

Early  in  the  feasibility  portion  of  the  study  (Section  3.  0),  an  initial 
comparison  of  major  bus  characteristics  revealed  that  all  but  two  of  the 
candidate  systems  exhibited  identical  characteristics  when  examined  to  this 
level.  The  two  exceptions  were  the  ARINC-type  buses  (specu.cally  ARINC 
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575)  and  the  F-15  multiplex  bus  (MDC  H009).  The  ARINC  575  bus  exhibited 
radically  different  characteristics  in  the  following  areas: 

•  Bus  Control 

•  Bus  Termination 

•  Modulation  Method 

•  Message  Format 

•  Word  Length 

•  Word  Synchronization 

•  Bit  Rate 

The  H009  bus  differed  significantly  in  the  areas  of: 

•  Bus  Structure 

•  Bus  Control 

•  Bus  Termination 

•  Message  Format 

•  Word  Length 

•  Word  Synchronization 

Based  on  these  findings,  it  was  concluded  that  it  was  not  feasible  to  impose 
ARINC  and  H009  compatibility  requirements  on  a  standard  remote  terminal, 
but  that  some  degree  of  data  interchange  could  be  achieved  by  the  use  of  an 
adapter /formatter  interface  between  the  two  buses. 

Such  an  interface  has  been  demonstrated  for  both  buses.  An  ARINC-575 
to  1553  Data  Exchange  Buffer  has  been  successfully  demonstrated  in  the  ASD 
SEAFAC  laboratory.  An  H009  to  1553  adaptor  is  presently  being  used  to 
interface  the  F-15  avionics  bus  to  the  MIL-STD-1553  interface  in  the  Air 
Force  ATIS  flight  test  instrumentation  system. 
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1.  3.  2 


Basic  Signal  Characteristics 


Although  investigation  of  basic  signal  characteristics  revealed  a  degree  of 
variation  especially  in  signal  levels,  practical  compatibility  does  not  pose 
a  serious  problem. 

Signal  characteristics  examined  include: 

•  Output  level 

•  Input  response  level 

•  Waveform  rise/fall  time 

•  Zero  crossing  deviation 

•  Clock  stability 

•  Output  noise 

•  Common  mode  rejection 

It  was  determined  that,  in  most  cases,  MIL-STD- 1 553B  requirements  were 
broad  enough  to  encompass  the  characteristics  of  the  other  systems.  It  is 
therefore  recommended  that  1553B  be  adopted  for  future  systems  and  that 
retrofit  to  existing  systems  be  accomplished  by  the  use  of  programmable 
output  levels  and  input  thresholds  but  only  to  the  minimum  extent  necessary 
to  establish  practical  compatibility. 

1.  3.  3  1553  vs.  A3818  Type  Waveform 

A  major  difference  in  bus  signal  characteristics  is  found  in  the  output 
waveform  of  the  F-18  system  (MDC  A3818),  which  specifies  a  sine  wave 
as  opposed  to  the  trapezoidal  waveform  of  1553  and  other  specifications. 
Attempts  to  design  a  bus  interface  which  would  be  compatible  with  both 
specifications  have  achieved  only  limited  success.  The  usual  method  is  to 
generate  a  trapezoidal  waveform  which  can  be  filtered  to  produce  a  sine 
wave.  This  invaribly  results  in  a  complex  circuit  which  produces  waveforms 
which  closely  approximate  both  specifications  but  actually  conform  to  neither. 
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For  this  reason,  it  is  recommended  that  modular  transmitters  be  used  which 
provide  the  capability  to  "plug  in"  either  a  =ine  wave  or  trapezoidal 
waveform  transmitter. 


1.3.4  Mode  and  Status  Codes 

Mode  and  status  code  assignments  vary  widely  among  the  candidate  systems. 

The  simplest  and  most  flexible  technique  for  accomplishing  compatibility  in 
this  area  is  to  store  mode  and  status  codes  for  a  selected  number  of  existing 
systems  plus  a  number  of  spares  in  PROMs  within  the  RT.  Such  a  unit 
would  be  pin-programmable  for  existing  systems  but  would  also  allow 
custom  programming  to  meet  future  requirements. 

1.  3.  5  Recommended  Programmable  Interface  Module  Configuration 

The  recommended  Programmable  Interface  Module  (PIM)  design  philosophy 

utilizes  a  three  processor  concept  in  a  distributed  microprocessor  arrangement 

to  achieve  the  desired  interface  compatibility  ( See  Section  5.  0).  The  speed  and 

v 

redundancy  requirements  of  the  PIM  dictate  the  division  of  the  interface  into  three 
independent  modules:  two  Bus  Interface  Modules  ( BIMs  )  and  a  Computer 
Interface  Controller  (CIC),  The  two  BIMs  provide  the  interfaces  to  the  dual 
redundant  MIL-STD-1553  busses  and  the  internal  PIM  data/control  bus.  The 
CIC  controls  the  internal  PIM  bus  and  also  handles  the  digital  interface  to  the 
user  subsystem.  The  three-processor  concept  allows  three  independent  soft¬ 
ware  -  controlled  events  to  occur  simultaneously,  thus  allowing  an  extremely 
high  degree  of  flexibility  both  for  existing  systems  and  future  growth. 


2.0 


MULTIPLEX  SYSTEM  DESCRIPTIONS 


The  thrust  of  this  program  is  on  Air  Force  Aircraft  that  employ  some  version 
of  MIL-STD-  1553,  with  secondary  consideration  given  to  other  aircraft 
multiplex  systems  operational  in  other  branches  of  the  military  service  and 
the  commercial  sector.  This  section  contains  a  description  of  each  of  the 
multiplex  systems  considered  in  the  study.  The  selected  systems  represent 
a  broad  spectrum  of  multiplex  systems  presently  in  use.  Several  revisions 
or  variations  of  MIL-STD-  1553  systems  are  represented  plus  non- 1553  systems. 

A  brief  discussion  of  MIL-STD-  1553  is  also  presented,  including  differences 
in  the  three  revisions.  MIL-STD-  1 553B  will  be  used  as  a  basis  for  comparison 
throughout  the  study. 

2.1  MIL-STD-  1553B 

MIL-STD-  1 553B  is  the  latest  version  of  a  standard  which  establishes 
requirements  for  aircraft  information  transfer  formats  and  electrical  inter¬ 
face  characteristics.  Avionics  integration  using  1553B  is  accomplished  by 
both  hardware  and  software.  The  standard  describes  information  transfer 
formats  which  are  originated  and  interpreted  with  software  and  electrical 
interface  characteristics  which  describe  the  data  transmission  technique. 

1553B  has  been  described  as  part  specification  and  part  standard,  the 
standard  portion  consisting  of  the  information  transfer  formats  and  the  elec¬ 
trical  characteristics  comprising  the  specification  portion.  The  information 
transfer  formats  and  electrical  characteristics  will  be  described  very  briefly 
in  this  section  with  additional  details  being  described  and  compared  as 
appropriate  in  the  section  which  follows. 
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2.  1.  1 


Information  Transfer  Formats 


The  term  or  phrase  "information  transfer  formats"  is  used  in  1553B  inter¬ 
changeably  with  "message  formats".  The  exchange  of  messages  in  1553B  is 
very  precisely  described,  and  there  are  only  10  allowable  formats.  If  an 
exchange  cannot  be  completed  because  of  hardware  or  software  failures,  then 
1553  describes  and  specifies  what  is  to  be  done.  All  methods  of  followup  to 
retry  the  message  or  to  determine  the  failure  must  be  done  within  the  allow¬ 
able  10  message  formats.  The  message  exchange  sequences  as  well  as  the 
message  formats  themselves  are  frequently  referred  to  as  1553  protocol. 
Message  formats  are  composed  of  words,  response  time  gaps,  and  inter¬ 
message  time  gaps.  There  are  only  three  types  of  words:  command  word, 
status  word,  and  data  word.  Message  formats  are  divided  into  two  groups: 
mode  commands  and  data  transfers. 

2.  1.  1.  1  Mode  Commands 

Mode  commands  are  those  formats  reserved  for  communication  with  the  bus 
hardware  and  information  flow  management.  Mode  codes  are  the  specific 
function  code  associated  with  a  mode  command. 

There  is  provision  for  32  unique  mode  codes,  and  1553B  specifies  the  base 
2  numbers  that  are  to  be  used  for  15  of  these.  The  balance  are  reserved, 
which  means  the  designer  must  secure  special  approval  to  use  a  reserved 
mode  code  number.  However,  the  use  of  any  or  all  defined  mode  codes 
is  optional. 

2.  1.  1.2  Data  Transfers 

Data  transfer  message  formats,  on  the  other  hand,  do  not  restrict  the  designer 
to  the  same  degree  as  mode  commands.  The  restrictions  are  (I)  no  more 
than  32  words  in  any  single  message  are  to  be  used  and  (2)  the  most  significant 
bits  of  any  value  or  quantity  will  be  transmitted  first,  with  bits  of  descending 
significance  following. 


2.  1.2 


MLL-STD-  1 553B  Terminals 


MIL-STD- 1553B  describes  three  types  of  terminals,  which  may  be  more 
accurately  described  as  operational  modes.  A  terminal  is  defined  as  "the 
electronic  module  necessary  to  interface  the  data  bus  with  the  subsystem  and 
the  subsystem  with  the  data  bus.  ..."  There  are  only  three  functional  modes 
of  terminals:  the  bus  controller,  the  bus  monitor,  and  the  remote  terminal. 
The  definition  of  a  terminal  as  an  electronic  module  should  convey  the  notion 
of  a  unit  that  contains  digital  logic  as  a  minimum  and  may  frequently  contain 
microprogrammed  LSI  or  a  microprocessor  with  instructions  in  ROM.  As  a 
bus  monitor  or  bus  controller,  the  usual  approach  is  a  connection  to  and  a 
dependence  on  a  minicomputer  for  functional  performance.  Significant  digital 
complexity  is  required  because  1553  specifies  response  time  and  data  storage 

requirements  that  require  dedicated  digital  hardware. 

f 

2.  1.2.1  Bus  Controller 

MIL-STD- 1553B  defines  the  bus  controller  as  "the  terminal  assigned  the  task 
of  initiating  information  transfers  on  the  data  bus".  Other  requirements  are: 
(1)  "The  bus  controller  is  the  key  part  of  the  data  bus  system,  "  and  (2)  "Sole 
control  of  information  transmission  on  the  bus  shall  reside  with  the  bus 
controller . "  These  quotes  clearly  define  the  bus  controller  mode. 

2.  1.2.2  Bus  Monitor 

The  standard  defines  the  bus  monitor  as  "the  terminal  assigned  the  task  of 
receiving  bus  traffic  and  extracting  selected  information  to  be  used  at  a  later 
time".  Bus  monitors  are  frequently  used  for  instrumentation. 

2.  1.  2.  3  Remote  Terminal 

Any  terminal  that  is  not  operating  in  either  bus  controller  or  bus  monitor  mode 
is  operating  in  the  remote  terminal  mode. 
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2.  1.3 


MIL-STD-  1553B  Words 


A  word  is  defined  by  the  1553B  standard  as  "a  sequence  of  16  bits  plus  sync 
and  parity".  Each  word  contains  the  sync,  which  is  3  bit  times,  and  parity, 
which  is  1  bit,  so  that  transmitted  words  in  a  1553B  system  are  always  20  bit 
times  in  length  for  each  16  bit  word.  There  are  only  three  types  of  words 
allowed  by  the  standard.  The  role  of  each  is  as  follows: 

•  Command  Word.  This  word  is  always  used  as  the  first  word  (or  words) 
of  a  message.  Therefore,  it  will  only  be  transmitted  by  a  bus  controller. 
This  word  defines  the  type  of  information  transfer  format  that  will  be 
used. 

•  Status  Word.  This  word  is  always  used  as  the  first  word  that  is  trans¬ 
mitted  by  a  remote  terminal.  (Bus  monitors  do  not  transmit  at  all). 

This  word  contains  the  status  of  the  transmitting  remote  terminal. 

•  Data  Word.  This  word  (or  words)  is  always  transmitted  contiguously 
with  a  command  word,  status  word,  and  other  data  words. 

2.1.4  Electrical  Characteristics 

The  key  electrical  characteristics  of  the  1553B  data  bus  are  as  follows: 

•  Data  Rate.  The  transmission  bit  rate  is  1.  0  megabit  per  second. 
Accuracy,  short-term  stability  and  long  term  stability  are  specified. 

•  Data  Code.  The  data  code  is  Manchester  II  biphase  level. 

•  Serial  Transmission.  The  signal  is  transferred  over  the  data  bus  in 
serial  digital  pulse  code  modulation  form.  Simultaneous  transmission 
and  reception  by  a  bus  controller  and  a  remote  terminal  are  not 
possible  on  the  same  data  bus.  If  the  serial  transmission  of  data  causes 
an  unacceptable  data  lag,  delayed  response,  or  capacity  problem, 
additional  buses  may  be  used. 
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Sync,  The  sync  waveform  is  three  bit  times,  with  the  sync  waveform 
being  positive  for  the  first  one  and  one-half  bit  times,  and  then  negative 
for  the  following  one  and  one- half  bit  times.  This  definition  is  for  the 
command  word  and  status  word  syncs.  Data  syncs  are  initially  a 
negative  pulse  followed  by  a  positive  pulse.  There  is  no  separate  clock 
line  or  source  for  synchronizing  the  receiver's  terminal. 

Intermessage  Gap.  The  bus  controller  provides  a  minimum  gap  time 
of  4.0  microseconds  between  messages. 

Response  Time.  The  remote  terminal  must  respond  to  a  valid  command 
word  within  the  time  period  of  4.  0  to  12.  0  microseconds. 

Hardware  Characteristics.  Hardware  characteristics  specified  by 
1553B  include  cable  and  cable  impedance,  attenuation,  termination, 
cable  stubs  (direct  and  transformer  coupled),  and  terminal  input  and 
output  characteristics  (waveform,  noise,  symmetry,  common  mode 
rejection,  and  impedance). 


2.2  F- 16  MULTIPLEX  SYSTEM 

The  F-16  is  an  air  combat  fighter  supplied  to  the  Air  Force  by  General 
Dynamics/Fort  Worth  Division.  The  F-16  development  program  coincided 
closely  with  the  initial  publication  of  MIL-STD-1553  (U5AF)  and  so  became 
the  first  vehicle  to  utilize  and  flight  test  a  MIL-STD-1553  compatible 
multiplex  data  bus  system. 

The  F-16  data  bus  system  is  characterized  by  an  extremely  simple  approach 
to  architecture,  bus  control,  redundancy  management,  mechanization  and 
bus  control  transition  technique. 


2.2.  1 


Application  Area 


The  F-16  data  bus  is  basically  limited  to  the  avion ics  system  (A MUX)  with 
essentially  all  major  avionics  subsystems  utilizing  the  bus  for  data  transfer. 
In  fact,  the  only  major  subsystem  absent  is  the  flight  control  system. 


Nine  different  Avionic  subsystems  interface  directly  to  the  F-16  data  bus: 

1.  Fire  Control  Computer  (FCC) 

2.  Fire  Control/Navigation  Panel  (FCNP) 

3.  Inertial  Navigation  Unit  (INU) 

4.  Fire  Control  Radar  (FCR) 

5.  Radar  E/O  Display  (REO) 

6.  Central  Air  Data  Computer  (CADC) 

7.  Head-Up  Display  (HUD) 

8.  Stores  Management  Set  (SMS) 

9.  Target  Identification  Set,  Laser  (TISL) 

All  electronics  required  to  interface  with  the  multiplex  bus  is  contained 
within  the  respective  subsystem,  thus  eliminating  completely  the  need  for 
stand-alone  "remote  terminals"  or  external  signal  conditioners.  Thus  each 
subsystem  provides  data  in  digital  form  to  the  bus  interface  internal  to  the 
system,  the  only  external  signal  interface  being  the  serial  multiplex  bus. 

2.2.2  System  Architecture 

The  physical  architecture  of  the  F-16  Avionics  data  bus  system  is  shown  in 
Figure  1.  A  dual  redundant  network  is  used.  With  the  exception  of  the 

Stores  Management  subsystem, which  is  fully  dual  redundant,  none  of  the 
subsystems  have  functional  redundancy.  The  dual  redundant  bus  is  utilized 
primarily  to  prevent  a  single  bus  fault  (cable  or  connector)  from  rendering 
the  system  inoperative. 
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Figure  1  F-16  Multiplex  System  Architecture 
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2.  2.  2.  1  MIL-STD-  1553  Compatibility 

The  F-16  data  bus  system  was  designed  to  be  compatible  with  the  interface 
requirements  of  MIL-STD- 1553  (USAF).  Because  1553  does  not 
contain  sufficient  information  for  specifying  procurable  hardware,  General 
Dynamics  chose  to  include  all  of  its  multiplex  data  bus  requirements  in  the 
F-16  Interface  Control  Document  (ICD). 

In  addition  to  the  specification  sheets  normally  included  in  an  ICD,  the  F-16 
ICD  contains  a  specification  (16PP188)  which  includes  the  essential  require¬ 
ments  of  1553  (USAF),  plus  additional  details  necessary  to  allow  it  to  be 
used  as  a  procurement  specification.  Supplementary  requirements  con¬ 
tained  in  16PP188  include  (1)  definitions  of  the  bits  in  the  bus  status  word, 

(2)  a  description  of  the  bus  redundancy  operation,  (3)  the  assignment  of 
terminal  addresses  and  subaddresses  and  (4)  necessary  constraints  on  time 
coherence.  These  requirements  are  examined  in  detail  in  Section  3.0. 

2.  2.  2.  2  Multiplex  Cable  Assembly 

The  F-16  data  bus  utilizes  an  extremely  short  cable  assembly.  Although 
1553  (USAF)  allowed  up  to  300  feet  of  cable,  the  F-16  main  bus  is  only 
17  1/2  feet  long.  All  subsystems  are  attached  to  the  bus  by  the  use  of  stubs 
which  are  connected  to  the  main  bus  by  transformer /resistor  coupling 
networks.  Except  for  provisions  for  the  TISL  system,  all  stubs  vary  in 
length  from  approximately  2.  5  feet  to  6  feet.  The  TISL  provision  includes 
a  15  foot  stub  to  an  externally  mounted  Pave  Penny  pod. 

Due  to  the  modular  assembly  techniques  used  by  General  Dynamics,  the 
isolation  networks  are  mounted  in  matrices  of  multiple  stub  terminations. 

The  isolation  networks  are  shielded  from  each  other  within  these  matrices. 
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2.  2.  2.  3  Bus  Protocol 


The  F-16  multiplex  data  bus  system  protocol  is  in  accordance  with  1553. 

All  transactions  are  command/ response  with  bus  control  centralized  in 
the  Fire  Control  Computer  (FCC).  A  back-up  bus  control  capability  resides 
in  the  INU.  Controller-to-terminal,  terminal-to-controlier  and  terminal- 
to-terminal  exchanges  as  defined  by  1553  are  utilized.  Terminal  addresses 
are  hard-wired  within  the  remote  terminals.  Any  subsystem  is  capable 
of  receiving  a  command  on  either  bus  at  any  time.  A  subsystem  always 
acts  on  the  latest  command  word  received.  If  a  second  command  word 
is  received  (on  either  bus)  while  a  previous  message  is  being  received, 
the  subsystem  interrupts  receipt  of  the  first  message  and  accepts  the 
latest  command.  This  feature  also  allows  a  transmission  on  one  bus  to 
be  interrupted  by  a  subsequent  command  on  the  second  bus. 


2.2.3  System  Control 

The  F-16  multiplex  data  bus  system  uses  an  extremely  simple  control 
philosophy.  The  Fire  Control  Computer,  when  operating,  acts  as  the  bus 
controller.  If  the  FCC  is  not  operating,  the  INU  assumes  bus  control.  This 
concept  is  further  simplified  by  the  restriction  that  the  FCC  can  never  operate 
as  a  remote  terminal. 
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2.2.4 


Bus  Controller 


While  other  major  subsystems  in  the  F-16  AMUX  system  have  data  processing 
and  memory  capabilities,  only  the  Fire  Control  Computer  is  in  actuality  a 
true  computer.  This  fact  plus  its  prominence  in  the  primary  data  flow  pattern 
figures  heavily  in  the  selection  of  the  FCC  as  the  primary  bus  controller. 

The  Intertial  Navigation  Unit  figures  most  prominently  in  the  data  flow  pattern 
should  the  FCC  fail.  Therefore,  the  INU  was  selected  to  perform  the  back¬ 
up  bus  control  function. 

Primary  bus  control  resides  in  the  software  of  the  FCC.  This  machine  is 
a  Delco  M362F  computer  procured  for  the  F-l6  and  programmed  by  General 
Dynamics.  Actual  bus  control  is  maintained  by  a  mic reprogrammable  hardware 
DMA  Controller  which  is  initiated  periodically  by  the  FCC  Operational  Flight 
Program  (OFP).  This  controller,  called  the  Serial  Data  Interface  (SDI)  reads 
and  executes  bus  transfer  sequences  stored  in  the  FCC  Main  Memory. 

Secondary  or  backup  bus  control  is  provided  by  the  Inertial  Navigation  Unit 
(INU).  The  INU  periodically  samples  the  bus  control  discrete  from  the  FCC 
and  assumes  bus  control  after  two  consecutive  "NO-GO"  samples. 

2.2,5  Remote  Terminal  x 

The  F-16  multiplex  data  bus  system  interfaces  with  and  provides  complete 
communication  with  nine  major  subsystems  as  listed  in  paragraph  2.  2.  1. 

All  bus  interfaces  are  integral  to  the  subsystems  they  serve.  This  approach 
drastically  reduces  integration  problems  as sociated  with  stand-alone  remote 
terminal/signal  conditioning  systems. 

Of  the  nine  subsystems,  seven  always  act  as  remote  terminals  only.  One, 
the  Fire  Control  Computer,  acts  as  the  primary  bus  controller  and  is  deleted 
from  system  communication  in  the  back-up  mode.  It  can  never  act  as  a 
remote  terminal.  Of  the  nine  subsystems  only  the  Inertial  Navigation  Unit 
can  act  as  either  a  remote  terminal  (in  the  primary  mode)  or  a  bus  controller 
(in  the  secondary  mode). 


Since  all  bus  interfaces  are  integral  to  the  subsystems  which  they  serve,  the 
usual  "subsystem  interface"  is  solely  the  responsibility  of  the  avionics 

supplier  and,  in  fact,  does  not  exist  external  to  the  subsystem.  Thus,  the 
communication  interface  with  the  subsystem  is  limited  to  the  1553 
bus.  None  of  the  F-16  subsystems  use  a  "standard"  interface  module.  The 
bus  interfaces  within  the  various  subsystems  represent  independent  designs 
by  six  different  suppliers. 

2.3  B-52  OAS  MULTIPLEX  SYSTEM 

The  B-52  Offensive  Avionics  System  (OAS)  is  a  retrofit  update  to  the  B-52 
avionics  being  incorporated  to  improve  mission  reliability,  reduce  life  cycle 
cost,  and  support  the  air-launched  cruise  missile  (ALCM)  weapons  system. 
The  OAS  uses  1553A  data  buses  as  its  information  transfer  medium.  The 
application  areas  of  the  multiplex  system  are  navigation,  stores  management, 
and  control  and  display.  The  multiplex  system  usea  two  active  and  standby 
pairs  of  data  buses. 

The  OAS  data  processing  is  basically  centralized.  The  data  bus  traffic 
includes  intertial  platform  da:a,  missile  alignment  data,  and  all  (except 
safety  related)  control  and  display  data.  Some  safety  aspects  excluded  from 
the  multiplex  buses  relate  to  nuclear  safety,  as  the  B-52  OAS  controls, 
monitors,  and  delivers  nuclear  weapons.  Nuclear  safety  and  survivability 
requirements  imposed  on  the  OAS  are  probably  unique  to  strategic  aircraft 
and  their  systems.  For  example,  the  OAS  must  remain  operational  during 
and  after  a  nuclear  event.  The  B-52's  navigation  system  is  required  to  be 
self-contained,  and  the  aircraft  must  not  become  "lost"  because  of  any  type 
of  transient.  These  safety  and  survivability  requirements,  along  with 
requirements  for  high  weapon  delivery  accuracies,  lead  to  subsystem  require¬ 
ments  to  store  critical  data  in  multiple  locations  and  to  recover  rapidly  from 
failures  and  upsets. 


Subsystems  receiving  and/or  transmitting  data  via  the  multiplex  data  bus  are 
as  follows: 

1.  Two  Avionics  Processors  (AP) 

2.  Two  Inertial  Measurement  Units  (IMU) 

3.  Doppler  Velocity  Sensor  (DVS) 

4.  Autopilot 

5.  Attitude  Heading  Reference  Svstem  (AHRS) 

6.  Air  Data  Elements 

7.  Four  Data  Transfer  Units  (DTU) 

8.  Electro- Optical  Viewing  Subsystem  (EVS) 

9.  Angle-Of-Attack  (AOA)  Computer 

10.  Advanced  Capability  Radar  (ACR) 

11.  Control  and  Display 

12.  Radar  Altimeter 

13.  Weapons  Control  and  Delivery  Svstem 

2.3.1  System  Architecture 

The  physical  architecture  of  the  B-52  OAS  multiplex  system  consists  of  four 
buses,  twisted-shielded  wire  pairs  terminated  at  both  ends  with  the  character¬ 
istic  impedance  of  the  wire  pair,  and  17  electronic  units,  each  connected  to 
two  or  all  four  of  the  buses.  Two  of  the  17  units  are  avionics  processors  and 
are  connected  to  all  four  buses.  Nine  units  are  connected  to  two  of  the  buses, 
and  six  units  are  connected  to  the  other  two  buses.  This  architecture  provides 
two  bus  pairs  with  each  avionics  processor  connected  to  both  (see  Figure  2). 

The  17  units  connected  to  the  1553A  buses  are  as  follows: 

1.  Navigation  and  Weapons  Delivery  Avionics  Processor  (NAWD-AP) 

2.  Control  and  Display  Avionics  Processor  (CAD-AP) 

3.  Interface  Electronics  Unit  #1  (IEU-#1) 

Interface  Electronics  Unit  #2  (IEU-#2) 


4. 


5.  Radar  Interface  Unit  (RIU) 

6.  EVS  Interface  Unit  (EIU) 

¥ 

7.  Armament  Interface  Unit  (AIU) 

8.  Display  Electronics  Unit  (DEU) 

9.  Doppler  Velocity  Sensor  (DVS) 

10.  Control  and  Display  Inteface  Unit  (CDIU) 

11.  Missile  Interface  Unit  --  Rotary  Launcher  (MIU-RL) 

12.  Missile  Interface  Unit  --  Left  Pylon  (MIU-LP) 

13.  Missile  Interface  Unit  --  Right  Pylon  (MIU-RP) 

14.  Four  Data  Transfer  Units  (DTU-A,  DTU-B,  DTU-C,  and  DTU-D) 

Functionally,  the  B-52  OAS  has  a  federated  computational  architecture  that 
uses  two  processors.  One  processor  performs  navigation  and  missile 
processing,  and  the  other  processor  performs  controls  and  displays  processing. 
In  the  event  of  a  processor  failure,  the  other  processor  has  been  specified  to 
perform  time  critical  and  critical  (but  not  noncritical  functions)  in  a  backup 
mode.  Four  1553A  buses  are  operating  as  two  active  and  standby  pairs, 
with  each  pair  controlled  by  a  separate  processor. 

2.  3.  1.  1  Documentation  and  Conformance  to  1553A 

The  system  specification  requires  the  use  of  1553A  data  buses.  A  Boeing 
document,  "B-52  OAS  Multiplex  Bus  Protocol"  (D675- 1 01 10- 1 ),  expands  on  the 
standard.  All  vendors  and  designers  were  required  to  use  this  document. 
RT-to-RT  and  broadcast  transmissions  are  not  used  in  the  OAS,  although  RT- 
to-RT  transmission  is  described  in  the  protocol  document. 

The  OAS  generally  complies  with  1553A.  The  status  word  and  mode  codes 
used  in  OAS  comply  with  1553A  but  are  different  from  those  required  by  1553B. 
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2.3.  1.2 


Bus  Network 


At  present,  the  OAS  bus  network  is  still  under  development,  and  the  length 
of  the  buses  and  stubs  has  not  been  finalized.  The  length  of  the  two  buses  on 
which  the  NAWD  processor  is  master  will  be  about  250  to  350  feet. 

Subsystem  equipment  relocation  is  being  studied  to  reduce  the  length  of  these 
NAWD  buses.  The  two  buses  controlled  by  the  CAD  processor  are  connected 
to  subsystems  concentrated  in  the  cockpit  and  forward  sections  of  the  B-52. 

The  CAD  buses  are  expected  to  be  relatively  short,  about  20  to  50  ft  in  length. 

The  OAS  multiplex  system  will  use  transformer-coupled  stubs.  Because  :-.i 
the  placement  of  certain  RTs,  such  as  the  MIU  for  the  rotary  launcher,  one 
or  more  very  long  stubs  may  have  to  be  used.  The  stub  for  the  MIU-RL  may 
be  40  ft  long.  To  compensate  for  waveform  distortion  at  the  receiver  of  this 
RT,  additional  filtering  of  the  received  signal  will  probably  be  incorporated. 

2.  3.  1.3  Bus  Protocol 

Bus  protocol  is  per  1553A.  All  transactions  are  strictly  command/response. 
Each  AP  is  the  bus  controller  on  one  pair  of  buses  and  an  RT  on  the  other 
bus  pair.  RT-to-controller  and  controller-to-RT  data  transmissions  are  the 
only  ones  that  are  implemented.  Mode  commands  can  be  transmitted  over  the 
bus  for  the  purpose  of  multiplex  system  management. 

RT-to-controller  and  controller-to-RT  transmissions  are  accomplished  by 
1553A  command,  data,  and  status  words.  The  command  and  data  word 
formats  are  as  specified  in  1553A.  The  specific  mode  and  and  status  codes 
implemented  in  the  OAS  will  be  discussed  later. 

2.3.2  System  Control 

Bus  control  is  based  on  the  ability  to  communicate.  Communication  status 
assessment  is  established  by  system  software  that  interrogates  each  LRU  at 
periodic  intervals  for  its  status  on  each  bus.  If  communication  is  not  attainable 
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after  three  consecutive  tries  on  one  bus,  then  the  operator  is  alerted  and  the 
failure  is  recorded  for  maintenance  action.  The  periodic  interrogation  interval 
will  be  long  enough  to  prevent  a  power  system  transient  from  falsely  indicating 
a  failed  LRU  or  bus. 

The  OAS  retry  scheme  is  software  selectable.  A  timer  determines  when  a 
message  is  not  received  (the  status  word  has  not  been  received  within  a 
specified  length  of  time),  and  a  retry  is  attempted  on  the  same  bus.  An 
interrupt  is  generated  after  the  third  failure.  This  can  be  inhibited  by  soft¬ 
ware,  so  that  an  interrupt  is  sent  to  the  CPU  after  the  first  failure.  The  latter 
approach  is  being  implemented  in  software  with  one  retry  being  made  on  the 
alternate  bus  and  a  maximum  of  six  retries  allowed  per  computer  frame. 

This  sequence  is  "fail  once,  retry  on  alternate;  fail  twice,  go  to  next  command". 

The  software  is  configured  during  normal  full-up  operation  with  two  active 
AP's  sharing  the  total  software  functional  responsibility  of  the  OAS  computa¬ 
tional  subsystem.  If  an  active  AP  fails  when  operating  in  the  full-up  mode, 
the  software  will  reconfigure  the  remaining  AP  into  the  backup  mode  of 
operation  to  provide  execution  of  all  time-critical  functions  within  500  ms  and 
all  critical  functions  within  a  specified  time  after  the  AP  failure. 

2.3.3  Bus  Controller 

The  AP-101C  processor  unit  is  a  general  purpose  processor  with  floating  point 
capability,  65,536  32-bit  words  of  core  memory,  and  six  1553A  bus  controllers 
for  communication  with  other  subsystem  elements.  Two  of  the  bus  controllers 
are  unused,  one  is  in  controller  mode,  two  are  in  remote  mode,  and  one  is  in 
quiescent  mode.  Data  transfers  can  be  initiated  only  in  the  controller  mode. 

One  bus  pair  is  connected  to  the  NAWD  interface  units;  this  bus  pair  is  called 
the  NAWD  bus  pair.  One  bus  pair  is  connected  to  the  CAD  interface  units  and 
the  four  DTUs;  this  bus  pair  is  called  the  CAD  bus  pair.  Each  bus  controller 
is  attached  to  a  1553A  serial  data  bus:  one  bus  of  a  pair  is  primary,  the  other 
bus  is  an  alternate  in  case  of  a  hardware  failure  on  the  primary  bus. 


Each  processor  has  separate  loads  that  are  identical  for  time-critical 
functions.  One  AP  executes  the  NAWD  programs,  and  one  AP  executes  the 
CAD  programs.  In  full-up  mode,  the  NAWD  AP  controls  the  buses  connected 
to  the  NAWD  interface  units,  and  the  CAD  AP  controls  the  buses  connected 
to  the  CADLinterface  units  and  the  DTUs.  In  backup  mode,  the  operational 
AP  controls  both  the  NAWD  bus  pair  and  the  CAD  bus  pair. 

In  the  remote  mode,  the  controller  responds  to  commands  received  over  the 
bus.  In  the  quiescent  mode,  the  controller  responds  to  commands  from 
the  CPU  and  ignores  any  traffic  over  the  bus. 

2.3.4  Remote  Terminal 

The  OAS  RTs  are  of  five  different  types,  made  by  five  different  manufacturers. 
Four  of  these  types  of  RTs  are  integral  to  the  subsystems.  The  fifth  type  of 
RT  can  be  integral  or  standalone,  depending  on  the  application. 

The  first  type  of  RT  is  integral  to  the  two  APs.  The  RT  function  is  a 
processor-controlled  mode  of  the  I/O  channels  of  the  IBM  AP-101C  processor. 

The  second,  third,  and  fourth  types  of  RTs  are  also  integral  to  their  sub¬ 
systems.  The  second  type  is  in  the  common  Doppler,  called  the  DVS  in  the 
OAS.  The  third  type  of  integral  RT  is  in  the  four  DTUs  that  are  built  by 
Sunstrand.  The  fourth  type  is  in  the  DEU  and  is  procured  from  Sperry. 

The  fifth  type  of  RT  is  built  by  Boeing  and  is  in  nine  of  the  units  connected  to 
the  OAS  data  buses.  The  nine  units  are  the  RIU,  the  EIU,  the  AlU,  the  CDIU, 
two  IEUs,  and  three  MIUs.  These  units  have  unique  subsystem  interfaces 
tailored  to  a  particular  application;  however,  ail  10  employ  a  common  inter¬ 
face  to  the  1553A  buses  called  a  common  core. 

The  two-card  B-52  OAS  RT  consists  of  a  dual  modem  card  to  interface  with 
two  multiplex  data  buses  and  a  handshaker  card  containing  a  256-byte  buffer 
memory.  Except  for  initialization,  the  OAS  RT  operates  independently  of  the 
user  who  interfaces  with  the  handshaker  card.  Data  words  received  or  trans¬ 
mitted  over  the  data  bus  are  stored  in  or  obtained  from  the  buffer  memory. 


2.4 


YAH- 64  ADVANCED  ATTACK  HELICOPTER  MULTIPLEX 
SYSTEM 


2.4.1  Application  Area 

The  YAH- 64  Advanced  Attack  Helicopter  (AAH)  is  being  developed  by  Hughes 
Helicopters  for  the  U.S,  Army.  It  is  tailored  specifically  for  the  day  and 
night  adverse  weather  antiarmor  mission.  A  1553A  multiplex  data  bus 
system  provides  avionics,  stores  management,  weapon  fire  control,  and 
cockpit  control  and  display  integration. 

In  addition  to  its  present  applications,  the  AAH  multiplex  system  may  be 
extended  to  include  other  applications.  Provision  is  being  included  for 
addition  of  the  Integrated  Avionics  Control  Set  (IACS)  to  the  AAH.  In  the 
future,  certain  information  required  by  the  flight  control  system  may  be 
routed  over  the  data  bus  from  avionic  sensors  to  the  Fire  Control  Computer 
(FCC).  From  the  FCC,  these  data  would  be  forwarded  to  the  flight  control 
system  either  over  dedicated  lines  or  to  a  1553A  RT  interfaced  to  the  flight 
control  system. 

Subsystems  receiving  and/or  transmitting  data  via  the  multiplex  data  bus  are 
as  follows: 

1.  Fire  Control  Computer  (FCC) 

2.  Doppler 

3.  Target  Acquisition  and  Designation  System  (TADS) 

4.  Pilot  Night  Vision  System  (PNVS) 

5.  Integrated  Helmet  And  Display  Sight  Subsystem  (IHADSS) 

6.  Hellfire  Missile  Control 

7.  Gun  Control 

8.  Rocket  Control 

9.  Electronic  Attitude  Director  Indicator  (EADI) 

10.  Symbol  Generator 
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11.  Heading  and  Attitude  Reference  System  (HARS) 

12.  Fault  Detection  and  Location  System  (FDLS) 

13.  Mis  s  ion  E  quipment 

2.4.2  System  Architecture 

The  AAH  multiplex  system  is  a  1553A  time-division  multiplex  system 
consisting  of  13  units  that  interface  directly  to  dual  redundant  data  buses. 
These  13  units  process  more  than  1,300  signals.  Of  the  13  units,  9  are  RTs 
specifically  designed  to  adapt  subsystems  to  the  multiplex  data  bus.  Where 
possible,  interfaces  to  RT  units  have  been  standardized  as  discrete  (bilevel), 
ac  and  dc  analog,  synchro,  and  serial  digital  data.  The  multiplex  system  can 
be  expanded  to  include  32  units  to  meet  future  requirements. 

Figure  3  is  a  block  diagram  of  the  present  AAH  multiplex  system.  The 
system  consists  of. 

A.  Dual  Redundant  Data  Buses 

B.  Two  Bus  Controllers  (primary  residing  in  the  Fire  Control  Computer; 
backup  residing  in  the  Copilot  Compartment  Remote  Terminal  Unit) 

C.  Symbol  Generator 

D.  Missile  System  Remote  Electronics  Unit 

E.  Electronic  Attitude  Director  Indicator  (EADI)  Remote  Electronics  Unit 

F.  Four  general-purpose  remote  terminal  units  located  in  the  pilot's 
compartment,  right  forward  avionics  bay,  left  forward  avionics  bay, 
and  aft  avionics  bay 

G.  Four  Pylon  Remote  Terminal  Units  (one  located  in  each  pylon) 

H.  Twenty- six  Data  Link  Termination  Units 

The  primary  data  bus  is  routed  along  the  left  side  of  the  aircraft,  while  the 
secondary  data  bus  is  routed  along  the  right  side.  This  isolation  between  the 
buses  increases  survivability.  The  two  bus  controllers  (FCC  and  backup  bus 
controllers)  are  widely  separated  for  the  same  reason.  Critical  signals  can 
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Figure  3  AAH  Multiplex  System  Architecture 


be  routed  into  separate  RT  units  by  providing  separate  signal  paths,  precluding 
the  loss  of  that  function  because  of  an  RT  malfunction. 


2.4.2.  1  Compliance  with  MIL-STD- 1553 

The  AAH  multiplex  system  generally  complies  with  1553A. 

Redundancy  is  achieved  in  transmission  lines,  bus  controllers,  and  RTs. 
Transmission  line  redundancy  is  provided  by  the  use  of  dual  redundant  data 
buses  in  an  active  and  standby  arrangement.  Two  bus  controllers  are  in  the 
system.  The  primary  bus  controller  resides  in  the  FCC.  The  backup  bus 
controller  (BBC)  is  part  of  the  copilot- gunner  (CPG)  RT.  The  two  bus  controllers 
operate  in  a  control  and  monitor  fashion.  In  the  RTs,  redundancy  is  provided 
by  dual  modems  and  some  duality  of  message  decoding  circuitry. 

The  multiplex  system  data  bus  operates  asynchronously  in  a  command/ 
response  mode,  with  transmissions  occurring  in  a  half-duplex  manner. 

2.  4.  2.  2  Multiplex  Cable  Network 

Each  of  the  multiplex  system  data  buses  consists  of  a  low-loss,  twisted  - 
shielded,  24-gage,  Teflon-insulated  wire  pair,  terminated  at  each  end  with 
its  characteristic  impedance  (71  ohms  nominal).  All  connections  to  the  data 
bus  system  use  a  small  data  link  termination  (DLT)  unit.  The  DLT  units 
provide  the  bus  with  short-circuit  isolation,  impedance  matching,  and  line 
termination.  One  DLT  unit  per  bus  is  used  for  each  terminal,  thereby 
requiring  two  DLT  units  per  terminal  for  the  dual  redundant  system. 

2.4.  2.  3  Bus  Protocol 

Information  flow  on  the  data  bus  is  composed  of  messages  and  words  per 
1553A.  Data  bus  messages  consist  of  controller-to-remote  transfers, 
remote-to-controller  transfers,  and,  although  not  presently  used,  remote-to- 
remote  transfers.  Data  bus  main  frame  time  is  a  nominal  20  ms.  During 
this  time,  the  active  bus  controller  collects  data  from  all  boxes  on  the  data 
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bus  (via  transmit  commands),  performs  the  required  logic  processing  and 
computations,  and  outputs  the  revised  data  to  all  boxes  on  the  data  bus  (via 
receive  commands).  For  subsystems  that  do  not  require  this  high  update  rate 
(50  times  per  second),  data  are  processed  and  outputed  at  a  lower  rate  (25 
times  per  second). 

2. 4.  3  System  Control 

The  strategy  for  retry  and  message  list  construction  after  a  message  trans¬ 
mission  failure  is  a  simple  one.  The  controller  will  always  use  the  channel 
that  worked  last  for  that  message.  For  example,  a  successful  transfer  on 
bus  A  would  result  in  the  next  transfer  of  the  same  message  also  being 
attempted  on  bus  A;  however,  if  the  first  attempt  on  bus  A  failed,  then  the 
retry  of  that  transmission  would  be  attempted  on  bus  B.  Thus,  communications 
will  continue  on  whichever  channel  is  functioning.  Note  that  the  retry  is 
limited  to  once  per  scan  of  the  message  list  and  is  always  initiated  on  the 
alternate  bus.  If  the  retry  fails,  the  message  is  skipped.  The  sequence  is 
"fail  once,  retry  on  alternate;  fail  twice,  go  to  next  message". 

During  normal  operation,  sole  control  of  information  transmission  on  the  bus 
resides  with  the  active  bus  controller,  which  initiates  all  transmissions. 

The  primary  bus  controller  resides  within  the  FCC,  while  the  BBC  resides  in 
the  RT  unit  located  in  the  copilot's  compartment. 

All  data  flow  is  controlled  by  addressed  command  words  from  the  active  bus 
controller  to  each  multiplex  RT  unit,  the  Symbol  Generator,  the  missile 
remote  electronic  unit,  and  the  EADI  electronic  unit. 

When  the  FCC  is  active  and  controlling  the  system,  the  BBC  monitors  bus 
activity.  The  BBC  automatically  assumes  control  of  the  system  if  the 
hardwired  FCC  signal  to  the  BBC  indicates  a  failure  or  if  there  is  a  loss  of 
data  transmissions  on  both  data  buses  over  a  specific  period  of  time. 
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2.  4.4 


Bus  Controller 


The  primary  bus  controller  resides  in  the  FCC.  The  FCC  is  a  MECA-43 
16-bit-word  hybridized  microcomputer  manufactured  by  Teledyne  Systems. 

It  is  a  general-purpose,  microprogrammed,  digital- parallel,  synchronous 
machine  with  16K  words  of  ROM  and  2K  words  of  RAM. 

The  1553A  bus  control  interface  was  designed  to  enable  the  Teledyne  FCC  to 
function  as  bus  controller  and/or  RT  in  a  dual  redundant  multiplex  data  bus 
system.  The  interface  complies  with  1553A  requirements  and  is  designed  to 
connect  directly  to  most  general-purpose  computers.  For  minimum  size  and 
weight,  all  circuit  components  are  in  dice  form  fabricated  in  hybrid  packages. 
There  are  three  functionally  unique  hybrids: 

A.  Driver-receiver  hybrid 

B.  Multiplex  Terminal  Unit  (MTU)  hybrid 

C.  Device  Control  Unit  (DCU)  hybrid 

The  driver-receiver  hybrid  couples  directly  to  a  dual  data  bus  system 
accommodating  TTL  control  and  data  signals  on  one  side  and  +10V  Manchester 
biphase  signals  on  the  bus  side.  The  MTU  provides  a  full-duplex  serial  inter¬ 
face  between  the  driver-receiver  and  DCU  hybrids.  MTU  functions  include 
code  conversion  between  NRZ  and  Manchester,  serial  timing  and  formatting 
for  I/O  data,  validity  checks  on  received  data,  and  a  total  message  length 
monitor.  The  DCU  performs  all  message-handling  requirements  of  a  bus 
controller  and/or  RT.  It  uses  the  computer's  main  memory  for  working 
storage  moving  data  in  and  out  via  direct  memory  access  (DMA). 

Backup  bus  control  is  provided  by  a  SDP-175  microprocessor  designed  and 
built  by  Sperry  Flight  Systems.  The  processor  is  located  in  the  CPG  RT  unit. 
The  290 1A  4-bit-slice  microprocessor  is  a  microprogrammed  digital 
computer  capable  of  performing  a  degrading  mission  function,  as  well  as 
backup  bus  control,  upon  loss  of  the  FCC.  The  SDP-175  has  12K  words  of 
ROM  and  2K  words  of  RAM. 
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The  BBC  is  unique  in  that  it  is  located  in  the  same  housing  as  an  RT  but  is 
functionally  separate  from  the  RT.  The  functions  are  split  between  RT  control 
and  BBC  in  such  a  way  that  the  RT  cannot  determine  whether  it  is  receiving  a 
command  from  the  primary  or  backup  controller.  Both  the  backup  bus  control 
computer  and  the  RT  control  transmit  their  information  on  the  data  bus  and 
respond  as  though  receiving  information  from  a  source  outside  their  own  box. 
The  functional  separation  of  RT  and  bus  control  allows  either  one  to  operate  in 
case  the  other  one  fails,  barring  failure  of  a  physically  shared  component 
such  as  a  power  supply  or  the  bus  interface  electronics. 


2.4.5 


Remote  Terminal 


As  presented  earlier,  13  units  are  connected  to  the  multiplex  data  bus.  Four 
of  these  units  (FCC,  remote  Hellfire  electronics.  Symbol  Generator,  and 
EADI  electronics)  have  imbedded  dual  redundant  1553A  interfaces.  The  other 
nine  units  are  multiplex  remote  terminal  units  (MRTU)  built  by  Sperry. 

The  RT  units  (identified  as  types  I,  II,  and  III)  input  and  output  a  standard 
assortment  of  bilevels,  ac  and  dc  analog,  serial  digital,  and  synchro  I/O 
signals  to  all  parts  of  the  aircraft.  To  fit  the  needs  of  the  YAH- 64  aircraft, 
these  units  contain  different  I/O  signal  capacities. 

All  RT  units  contain  dual  redundant  1553A  data  bus  interfaces.  When  further 
redundancy  is  required,  such  as  for  a  critical  input  or  output  signal,  that 
particular  signal  is  wired  into  two  separate  RT  units. 

Each  RT  unit  contains  sufficient  BIT  circuitry  to  detect  95%  of  all  faults 
(weighted  by  failure  rate)  within  itself.  At  the  LRU  level,  these  units  contain 
an  internal  test  system  to  check  input  and  output  channels  for  integrity  as 
well  as  power  supplies  and  other  internal  circuitry.  A  hardware  timeout 
function  is  provided  in  the  RT,  to  shut  off  a  continuous  transmission  by  a 
faulty  transmitter. 
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A  unique  feature  of  the  RTs  is  that  MRTU  type  HI  contains  the  SDP-175 
microprocessor.  As  presented  previously  during  the  discussion  of  backup 
bus  control,  the  SDP-175  serves  the  AAH  as  a  backup  mission  computer  and, 
in  the  multiplex  system,  as  a  bus  monitor  and  backup  bus  controller.  The 
functional  separation  of  the  RT  and  backup  bus  control  functions  of  MRTU 
type  HI  is  noteworthy. 

2.5  F- 18  FIGHTER /ATTACK  AIRCRAFT  MUT1PLEX  SYSTEM 

The  F-18  aircraft  was  developed  by  McDonnell  Aircraft  for  the  U.  S.  Navy 
and  Marine  Corps  in  cooperation  with  the  Northrop  Corporation.  The  fighter 
has  been  configured  for  optimum  performance  in  the  medium  range,  beyond- 
visual  attack  as  well  as  the  visual  short  range,  high-g  combat.  The  avionics 
utilize  digital  technology  to  the  maximum  extent  possible  with  major  emphasis 
on  demonstrated  reliability.  A  key  element  in  the  avionics  reliability  is  the 
capability  to  reliably  transfer  digital  data  between  sensor,  processors  and 
displays  located  throughout  the  aircraft.  This  transfer  of  digital  data  to  the 
mission  computers  is  accomplished  by  multiplexing  data  from  each  of  the 
major  avionic  subsystems  into  a  continuous  bit  stream  and  transmitted  over 
a  common  bus. 

2.  5.  1  Application  Area 

The  F-18  data  bus  provides  data  transfer  between  two  mission  computers  and 
the  avionics  subsystems.  The  subsystems  which  interface  directly  to  the  bus 
are: 

1.  Mission  Computer  No.  1 

2  Mission  Computer  No.  2 

3.  Flight  Control  Electronics  No.  1 

4.  Flight  Control  Electronics  No.  2 

5.  Stores  Management 

6.  Air  Data  Computer 
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7.  Maintenance  Data  Recorder 

8.  TACAN 

9.  Communications  System  Control 

10.  Inertial  Navigation 

11.  Radar 

12.  HUD/MFD  Symbol  Generator 

13.  Laser  Spot  Tracker 

14.  Forward  Looking  Infra-Red 

15.  MMD  EHSI  Symbol  Generator 

All  of  the  bus  interface  electronics  are  physically  contained  within  each  sub¬ 
system.  This  integrated  system  approach  avoids  the  proliferation  of  additional 
boxes  ttuit  v-ould  be  required  if  the  terminals  were  physically  separated  from 
the  subsystems  and  packaged  as  aline  replaceable  unit.  Consequently  the 
additional  costs  of  qualification,  installation,  cabling,  spares,  logistics,  hand¬ 
books,  AGE  and  training  for  the  additional  LRUs  are  avoided.  In  addition, 
the  integrated  approach  simplifies  the  system  specification  and  management 
of  interfaces  and  permits  clear  definition  of  responsibility  for  subsystem 
performance. 

2.5.2  System  Architecture 

The  F-18  bus  architecture  consists  of  two  independent  mission  programmed 
processors  which  interface  with  two  independent  data  channels.  Remote 
terminal  or  subsystems  transmit  and  receive  data  on  an  assigned  data  channel 
which  is  common  to  both  processors.  This  permits  each  processor  to 
command  data,  mode  change  or  status  from  remote  terminals  on  either  data 
channel. 

The  two  mission  computers  interface  with  each  of  the  avionics  subsystems 
using  a  redundant  bus  pair  for  each  data  channel.  The  F-18  system  archi¬ 
tecture  is  represented  by  Figure  4, 
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Figure  4  F-lb  System  Architecture 
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2.^.2.  1  MIL-STD- 1553  Compliance 

The  F-18  data  bus  system  follows  generally  the  design  configuration  and  bus 
characteristics  set  forth  in  MIL-STD- 1553  (USAF).  Additional  details  and 
some  exceptions  are  included  in  MDC  specification  A3818,  the  F-18  multiplex 
document. 

One  of  the  unique  features  of  the  F-18  bus  is  the  use  of  line  driver  filtering 
to  reduce  the  harmonic  level  of  the  transmitted  signal.  The  effect  is  to 
produce  a  sinewave  output  waveform  on  the  bus  as  opposed  to  the  trapezoidal 
signal  of  1553.  Although  this  waveform  is  not  technically  compliant  with 
1553,  the  hardware  is  compatible  since  a  1553  receiver  must  also  respond  to 
a  sinewave  due  to  the  filtering  effect  of  the  bus. 

2.  5.  2.  2  Multiplex  Cable  Assembly 

The  F-18  multiplex  cable  is  in  general  accordance  with  1553.  Transformer 
coupling  to  a  twisted  shielded  pair  cable  is  used  with  balanced  line  drivers 
and  receivers.  One  significant  difference  in  the  cable  coupling  technique  is  the 
requirement  for  center  taps  on  the  coupling  transformers.  All  center  taps 
are  connected  to  airframe  ground. 

2.  5.  2.  3  Bus  Protocol 

The  F-18  multiplex  system  protocol  is  in  accordance  with  1553.  All  trans¬ 
actions  are  command-response  with  bus  control  centralized  in  one  mission 
computer.  Backup  bus  control  resides  within  a  second  mission  computer. 

The  F-18  uses  the  two  mission  computers  and  associated  bus  controllers  in 
the  normal  mode  that  communicate  with  a  number  of  distributed  subsystem 
computers /processor s  in  a  hierarchal  system  architecture.  Mission  related 
functions  such  as  navigation,  flight  control,  communications,  fire  control, 
weapon  delivery,  display  data  base  management  and  stores  management 
are  assigned  to  a  specific  mission  computer.  Backup  programs  in  each 
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computer  provide  a  significant  fail  operational  capability.  Each  data  channel 
uses  a  redundant  bus  pair  for  additional  dependability.  Each  bus  is  monitored 
by  all  remote  terminals  on  the  data  channel.  Other  features  include  the  F-18 
use  of  the  mode  command  transfer  option  described  in  MIL-STD- 1553  to 
command  remote  terminal  mode  changes.  For  example,  a  mode  command  to 
the  autopilot  can  result  in  a  change  to  the  outer  loop  mode  and  an  autopilot 
response  with  a  status  word  indicating  message  acknowledge. 

2.  5,  3  System  Control 

The  avionics  multiplex  data  transfer  between  the  two  mission  computers  is 
shown  in  the  functional  block  diagram  (Figure  5).  Each  computer  has 
three  I/O  channels.  Each  remote  terminal  transmits,  receives  and  processes 
data  on  bus  "X"  while  simultaneously  monitoring  bus  "Y"  for  commands  from 
either  mission  computer.  In  the  event  a  valid  status  is  not  received  by  a 
controller  in  response  to  a  command  word,  the  controller  will  shift  to 
multiplex  bus  "Y"  and  repeat  the  command.  Although  this  backup  access  to 
data  from  remote  terminals  meets  stringent  fail  operational  requirements, 
two  additional  methods  of  data  access  are  inherent  to  the  bus /controller 
architecture.  First,  data  channel  "C"  is  available  for  transfer  of  data  base 
information  from  one  computer  to  the  other.  Since  dynamic  data  from 
remote  terminals  is  updated  at  ZO  times  per  second,  the  transferred  data  is 
compatible  with  mission  dynamic  requirements.  A  second  potential  data 
access  method  would  require  additional  software  to  permit  the  second 
computer  to  request  data  from  a  terminal  and  relay  it  to  the  first  computer. 
Due  to  the  survivability  of  the  dual  processors  and  redundant  MUX  bus,  this 
access  method  will  be  reserved  for  growth  or  future  priority  requirements. 

Since  both  controllers  have  access  to  each  data  channel,  it  is  necessary  to 
establish  control  logic  and  priority  for  channel  usage.  In  the  initial  or 
start-up  condition,  each  controller  is  programmed  to  transmit  on  an  assigned 
bus  as  illustrated  in  the  previous  block  diagram.  In  other  words,  mission 
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computer  "one"  will  transmit  on  data  channel  "B"  and  mission  computer  "two" 
will  transmit  on  data  channel  "A".  Channel  control  is  transferred  between 
computers  using  the  dynamic  bus  allocation  mode  command.  When  a  given 
controller  has  completed  all  its  required  transfers,  it  will  send  the  dynamic 
bus  allocation  mode  command  to  the  other  controller.  Receipt  of  the  mode 
command  is  acknowledged  and  the  second  controller  takes  command  of  the 
channel.  When  the  second  controller  has  completed  its  use  of  the  bus,  it 
returns  bus  control  to  the  first  controller.  Each  controller  monitors  the 
bus  priority  to  ensure  that  each  channel  is  properly  managed;  if  channel 
control  is  not  transferred  properly,  the  offending  controller  can  be  shut 
down  and  the  remaining  controller  takes  over  in  a  backup  mode.  In  addition, 
a  "watchdog"  timer  is  used  in  accordance  with  the  660  microsecond  trans¬ 
mission  time-out  specified  by  1553  to  detect  that  the  operational  program  has 
stopped  or  is  abnormally  delayed.  A  further  requirement  which  is  critical 
in  the  operation  of  two  independent  controllers  is  the  careful  design  of  soft¬ 
ware  to  insure  that  the  bus  utilization  time  by  each  controller  does  not  exceed 
the  total  capability. 

2.  6  F-  15  AIR  SUPERIORITY  FIGHTER  AIRCRAFT  MULTIPLEX  SYSTEM 

The  F-15  multiplex  system  is  unique  among  the  systems  considered  in  that 
it  predates  all  aircraft  multiplex  standards.  The  need  for  an  avionics  data 
bus  became  apparent  when  the  initial  RFP  was  released  in  1968.  The  concept 
of  using  a  digital  multiplexing  system  for  a  majority  of  the  data  exchanges  in 
an  avionics  subsystem  was  new  both  to  MCAIR  and  to  avionics  suppliers. 

IRIG  Std-106  and  MIL-STD-442  were  the  basic  standards  for  multiplexed  data 
transmission  at  that  time.  These  standards  were  primarily  designed  for  the 
telemetry  systems  to  be  used  in  instrumentation  applications,  and  were  not 
considered  suitable  for  an  avionics  data  bus.  As  a  result,  it  was  necessary 
for  MCAlR  to  develop  a  multiplex  system  specification  applicable  to  all  F-15 
avionics  sets  which  were  to  interface  with  the  data  bus.  MCAIR  Report  H009, 
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"F-15  Digital  Interface  Design  Specification,  "  was  created. 

The  H009  Report  defines  a  standard  interface  by  specifying  the  characteristics 
of  the  signals  on  the  bus,  plus  the  operating  procedure  and  data  format  for 
transferring  data  over  the  bus.  It  was  not  intended  to  specify  a  multiplex 
terminal  detailed  configuration,  only  operational  performance.  A  multiplex 
terminal  compatible  with  the  specified  interface  is  supplied  as  an  integral 
part  of  each  avionics  set  by  the  set  supplier,  with  the  reliability  and  qualifi¬ 
cation  requirements  for  the  terminal  included  in  those  specified  for  the  set. 

2.6.  1  Application  Area 

The  F-15  multiplex  system  was  designed  to  satisfy  a  very  specific  require¬ 
ment;  i.  e.  ,  the  exchange  of  digital  data  between  the  central  computer  and 
major  sets  of  a  highly  integrated  avionics  subsystem  installed  in  an  F-15  Air 
Superiority  Fighter  Aircraft. 

The  avionics  subsystems  which  interface  to  the  bus  are: 

1.  Central  Mission  Computer  (CMC) 

2.  Radar 

3.  Attitude  and  Heading  Reference  Set  (AHRS) 

4.  Air  Data  Computer 

5.  Signal  Data  Recorder 

6.  Navigation  Control  and  Indicator 

7.  Head  Up  Display  (HUD) 

8.  Inertial  Navigation  Set  (INS) 

9.  Lead  Computing  Gyro  (LCG) 

10.  Radar  Homing  and  Warning 

11.  Armament  Control 

12.  Horizontal  Situation  Indicator 

13.  Multi-Purpose  Indicator 
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All  data  bus  interface  electronics  are  contained  within  the  respective 
subsystems.  No  stand-alone  remote  terminals  are  used. 


2.6.2 


System  Architecture 


The  F-15  Avionics  system  employs  a  federated  architecture  made  up  of 
a  number  of  sets  containing  digital  data  processors  which  vary  in  size  and 
capability.  Therefore,  a  multiplex  bus  was  an  obvious  choice  to  handle  data 
exchanges.  The  data  bus  architecture  is  illustrated  in  Figure  6. 


2.6.2.  1 


Relation  to  MIL-STD- 1553 


The  salient  design  features  of  the  F-15  Avionics  Data  Bus  are  very  similar 
to  MIL-STD-  1553  in  many  respects.  There  are,  however,  a  number  of 
significant  differences.  Like  MIL-STD- 1553,  the  F-15  Data  Bus  is  a  party  line 
bus  using  digital  time  division  multiplexing  and  operating  in  the  half  duplex  mode. 
Bus  traffic  is  controlled  by  the  mission  computer  (bus  controller)  using  command/ 
response  techniques.  Data  words  which  contain  16  data  bits  plus  a  parity  bit  are 
transmitted  in  variable  length  messages  of  from  1  to  15  words.  (1553  allows  up  to 
32  words  in  a  message.  )  The  addressee  or  source  and  contents  of  the  message 
are  defined  in  the  Select  Word  which  precedes  all  messages.  (1553  uses  a 
Command  Word  which  carries  the  same  information  in  a  different  format). 

Data  bits  are  transmitted  at  a  rate  of  1  Mbps,  using  base  band  PCM  with  bi¬ 
phase  coding,  over  a  twisted  shielded  pair  (TSP)  transmission  line  having  a 
characteristic  impedance  of  68  ohms.  (1553  uses  a  70  ohm  TSP). 

The  signals  appearing  on  the  transmission  line  very  closely  resemble  1  MHz 
sine  waves  since  the  harmonic  content  of  the  data  is  limited  above  1.5  MHz. 

Data  signals  which  are  all  logical  one's  or  all  logical  zero's  look  like  1  MHz 
sine  waves.  Data  signals  of  alternating  logical  one's  and  zero's  are  500  KHz 
sine  waves  mixed  with  1.5  MHz  3rd  harmonic  components.  This  produces  a 
wave  form  with  a  zero  transition  which  very  closely  approximates  the  zero 
transition  of  a  1  MHz  sine  wave. 
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The  F-15  Data  Bus  uses  a  1  MHz  reference  clock  signal  generated  in  the 
mission  computer  and  distributed  to  all  the  peripherals  over  a  clock  trans¬ 
mission  line  separate  from  the  data  line.  (1553  generates  a  reference  clock 
signal  from  the  data  signal  in  each  terminal).  This  reference  clock  is  used 
for  synchronous  bit  detection  and  word  handling.  It  also  allows  word  and 
message  synchronization  without  the  use  of  special  sync  pulses  or  additional 
special  bit  patterns.  Data  words  on  the  bus  are  in  exactly  the  same  form  as 
the  data  in  the  computer  memory  and  terminal  logic.  The  absence  of  valid 
data  signal;  i.  e.  ,  no  valid  biphase  signals  above  the  threshold,  on  the  data 
line  for  eight  reference  clock  periods  indicates  a  new  message  is  to  be 
initiated  and  directs  all  terminals  to  resynchronize  and  prepare  to  receive  a 
new  Select  Word.  (1553  uses  a  3  usee  period  of  invalid  code  immediately 
preceding  the  Command  Word). 

Data  words  in  a  message  are  separated  by  gaps,  no  data  on  the  line,  of  exactly 
five  clock  periods.  (1553  uses  a  3  usee  period  of  invalid  code  to  separate 
words  in  a  message).  Data  transmissions  from  a  peripheral  in  response  to 
a  Select  Word  follow  that  word  by  exactly  5  reference  clock  periods. 

(1553  requires  a  response  to  a  Command  Word  in  4  to  12  usee).  Data  bits 
from  the  peripheral  are  transmitted  in  phase  with  the  reference  clock  from 
the  CMC;  therefore,  they  are  out  of  phase  with  the  clock  when  received  at  the 
computer.  This  phase  difference  is  approximately  twice  the  propagation  time 
from  the  computer  to  the  peripheral.  If  the  total  line  length  is  no  greater  than 
70  feet,  these  delays  are  tolerable  and  do  not  affect  synchronous  handling  of 
data  at  the  computer. 

The  reference  clock  signal  is  also  used  to  identify  which  of  the  two  redundant 
buses  is  to  be  used  for  data  transmissions.  When  the  mission  computer 
wishes  to  use  one'-of  the  two  redundant  buses,  the  reference  clock  signal  is 
brought  up  on  the  clock  line  of  the  selected  bus.  Clock  signals  look  exactly 
like  data  signals  of  all  logical  one's;  i.  e. ,  a  1  MHz  sine  wave.  The  presence 


of  a  clock  signal  on  a  bus  for  more  than  8  clock  periods,  with  no  data  on  the 
bus,  indicates  a  new  message  will  be  initiated  on  that  bus.  If  the  clock  signal 
goes  down  while  a  terminal  is  transmitting,  the  transmitter  is  shut  down  and 
all  the  peripheral  terminals  go  to  the  Receive  Mode,  resynchronize  and  pre¬ 
pare  to  receive  a  new  Select  Word.  This  type  of  resynchronization  is  used  if 
the  CMC  recognizes  transmission  of  format  errors  on  the  bus;  i.  e. ,  invalid 
c^ata  bits,  parity  errors,  incorrect  word  length  or  spacing.  Dropping  the 
dock  signal  can  also  signify  a  terminal  is  to  cease  transmissions  because  the 
mission  computer  wants  to  regain  control  of  the  bus. 

2.  6.  2.  2  Multiplex  Transmission  Line 

The  shielded  twisted  pair  transmission  line  used  to  implement  the  F-15  data 
buses  is  very  similar  to  regular  aircraft  wire,  except  that  the  characteristic 
impedance  is  controlled  to  68+4  ohms.  The  data  and  clock  bus  cables  are 
incorporated  into  aircraft  wire  bundles  using  standard  connectors  without 
special  handling.  Regular  line  splices  are  used  to  connect  the  lines,  except 
that  the  splices  are  shielded  to  reduce  emissions.  No  special  coupling  boxes 
(as  described  in  1553)  are  used  because  this  concept  is  not  compatible  with 
F-15  wire  bundle  fabrication  and  installation  in  the  compact  avionic  compart¬ 
ments  of  the  F-15. 

The  receiving  branches  of  the  bus  network  are  terminated  by  the  high  input 
impedance  of  the  terminals.  No  transmission  line  terminating  resistors  are 
used  at  the  ends  of  the  line,  (1553  uses  two  terminating  resistors,  each 
equal  to  the  characteristic  impedance  of  the  line).  The  transmission  line  has 
a  multi-forked  character  in  the  bus  network  configuration  resulting  from  the 
compact  wiring  installation  in  the  aircraft.  This  is  particularly  true  when 
viewing  the  bus  network  from  all  the  various  subscriber  terminals  which  will 
be  used  as  driving  points.  The  terminal  transmitters  have  a  source  impedance 
equal  to  the  characteristic  impedance  of  the  line,  which  minimizes  secondary 
reflections  from  the  driving  point.  Since  the  total  transmission  line  length 
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(approximately  70  feet)  is  a  small  portion  of  an  electrical  wave  length  at  the 
primary  frequency  of  1  MHz  and  frequencies  higher  than  1.5  MHz  are  attenu¬ 
ated  prior  to  transmission,  the  primary  reflections  do  not  produce  significant 
signal  wave  form  distortion. 

Multiplex  terminals  are  transformer  coupled  to  the  line  in  a  balanced-to- 
ground,  center-tap  grounded,  configuration.  (1553  does  not  specify  grounded 
center  tap).  Terminals  present  a  high  impedance  (5K  ohm  resistive  component 
at  1  MHz)  to  the  transmission  line  in  the  receiving  mode.  (1553  specifies  2K 
ohms  at  100K  Hz  to  1  MHz).  In  the  transmitting  mode,  the  source  impedance 
of  the  terminal  is  68  ohms.  (1553  does  not  specify  a  source  impedance,  but 
specifies  two  52.5  ohms  isolating  resistors  in  series  with  the  output.) 

2.6.  2.3  Bus  Protocol 

The  central  mission  computer(CMC)  performs  mission  oriented  computations 
which  generally  involve  data  inputs  from  more  than  one  remote  terminal  and 
exercises  overall  control  of  the  avionics  subsystem,  including  operating  as 
the  bus  controller.  The  mission  computer  either  uses  or  generates  most  of 
the  data  on  the  bus;  there  is  very  little  requirement  for  data  exchanges 
directly  between  remote  terminals  over  the  data  buses.  Therefore,  the 
multiplex  system  is  designed  so  that  all  data  exchanges  go  through  the  CMC  and 
no  direct  RT  to  RT  transfers  are  made.  As  a  result,  the  CMC  data  bus  and 
remote  multiplex  terminals  operate  as  an  extension  of  the  computer  I/O  using 
Command/Response  operation.  The  CMC  only  controls  the  transmission  and 
reception  of  data  from  remote  terminals  and  associated  buffer  memories;  it 
does  not  exercise  control  over  any  data  processing  or  conversion  in  remote 
units  other  than  to  command  a  subsystem  operating  mode  in  response  to  the 
pilot's  selection  of  desired  system  modes  of  operation. 

Since  the  majority  of  data  exchanges  in  the  avionics  subsystem  are  handled 
over  the  multiplexed  data  bus,  a  redundant  bus  is  provided  to  increase 
communication  reliability.  Either  of  the  two  data  buses  can  handle  data  at 


any  one  time.  The  bus  to  be  used  for  each  data  exchange  is  selected  by  the 
CMC  on  the  basis  of  current  performance.  Each  of  the  buses  uses  two  shielded 
twisted  pair  transmission  lines;  one  for  data  signals  and  one  for  clock  signals. 

In  addition,  the  data  bus  is  divided  into  two  separate  redundant  pairs,  each 
servicing  six  sets.  This  reduces  the  number  of  peripherals  serviced  through 
a  single  CMC  terminal  with  the  object  of  reducing  bus  traffic,  the  electrical 
load  on  the  bus,  and  the  physical  length  of  the  bus. 

There  are  two  one  way  dedicated  buses  in  the  F-15  avionics  Bystem  in 
addition  to  the  CMC  data  buses.  Both  of  these  use  the  same  signal  and  data 
formats  as  the  CMC  bus,  but  use  a  discrete  signal  over  a  separate  line  to 
request  data  rather  than  a  Select  Word  sent  over  the  data  bus.  One  bus 
operates  between  the  Inertial  Navigation  Set  (INS)  or  the  Attitude  and  Heading 
Reference  Set  (AHRS)  and  the  Radar.  The  INS  supplies  attitude  data  to  the 
Radar  at  a  much  higher  (250  sample/s econd)  data  rate  than  the  CMC,  which 
operates  at  a  rate  of  20  samples  a  second.  If  the  INS  is  "NO-GO",  the  AHRS 
senses  this  condition  and  responds  to  the  request  for  data  from  the  Radar. 

The  Head-Up  Display  (HUD)  also  listens  on  this  bus  and  uses  attitude 
information  from  this  bus  for  a  back-up  display  if  the  CMC  is  not  supplying 
attitude  data.  The  second  bus  is  used  to  transmit  gun  sight  data  from  the 
Lead  Computing  Gyro  (LCG)  to  the  HUD,  If  the  HUD  cannot  get  the  required 
data  from  the  CMC  bus,  it  switches  over  to  the  LCG  bus  and  reauests  alternative 
gun  sight  data.  This  Drovides  a  back-up  gun  mode  which  is  independent  of  the 
CMC. 

2.  7  ARINC  575  DIGITAL  AIR  DATA  MULTIPLEX  SYSTEM 

The  present  generation  of  commercial  aircraft  utilize  digital  data  buses  on 
an  individual  system  basis  and  it  is  certain  that  an  even  wider  useage  will  be 
common  on  the  next  generation.  A  basic  problem  exists,  however,  in  that 
commercial  aircraft  digital  data  buses  differ  from  the  MIL-STD-1553  buses 
in  concept  and  operation  and  the  two  are  generally  not  compatible. 
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Present  commercial  standards  were  written  by  Aeronautical  Radio,  Inc. 
(ARINC).  ARINC  is  supported  by,  and  is  responsible  to,  the  airline  industry. 
ARINC  sponsors  the  Airline  Electronic  Engineering  Committee  (AEEC)  which 
formulates  standards  in  the  form  of  characteristics  and  specifications  for 
airline  electronic  equipment  and  systems.  AEEC  subcommittees  provide  an 
open  forum  where  avionic  system  development  and  characteristic  preparation 
can  be  conducted  with  all  interested  parties  present. 

With  the  advent  of  digital  technology,  serial  digital  data  buses  evolved  rather 
naturally  to  replace  their  analog  counterparts.  The  serial  data  buses  were 
developed  by  the  groups  developing  the  basic  sensors.  Each  sensor  had 
several  parameters  to  be  transmitted  on  the  bus  for  reception  by  one  or  more 
user  terminals. 

A  word  format  was  developed  which  consisted  of  a  label  to  indicate  the 
particular  parameter  being  sent,  followed  by  the  parameter  data  and  any  sign 
or  status  indications.  The  sensors  and  indicator  units  could  be  built  and 
supplied  by  different  manufacturers.  Therefore,  the  data  transmission 
system  was  fully  defined  to  ensure  unit  interchangeability.  This  development 
philosophy  led  to  several  features  which  were  first  incorporated  in  1971  into 
the  "Digital  Air  Data  System"  characteristic  ARINC  575. 

It  can  be  easily  understood,  therefore,  that  the  commercial  bus,  evolving 
from  somewhat  different  requirements,  would  differ  in  many  areas  from  its 
military  counterpart. 

2.  7.  1  Bus  Protocol 

Although  both  bus  systems  communicate  via  serial  data  over  a  single  twisted 
shielded  pair,  they  are  different  in  many  respects.  Probably  the  most  far- 
reaching  difference  comes  under  the  heading  of  "Protocol".  The  575  bus 
operates  in  a  broadcast  mode,  i.  e.  ,  a  single  transmitter  sends  data  to  a 
maximum  of  20  receivers.  Only  one  transmitter  is  allowed  on  a  bus,  there- 
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fore,  multiple  buses  are  needed  to  allow  for  multiple  transmitters.  Any  unit 
receiving  data  from  more  than  one  source  is  required  to  have  a  separate 
input  for  each  source.  Since  communication  is  one-way  only,  no  feedback 
concerning  the  status  of  the  receivers  is  allowed.  Also,  any  garbled  messages 
will  be  lost  since  the  receivers  cannot  request  a  repeat.  An  advantage  of  the 
575  bus  over  1553A  is  that  the  receivers  and  transmitters  are  significantly 
simpler  in  design  and  much  slower  speeds  are  required. 

2.  7.  2  Application  Area 

The  ARINC  575  bus  was  originally  developed  to  meet  the  needs  of  commercial 
aircraft.  The  following  features  of  575  satisfied  these  needs: 

•  A  broadcast  bus  satisfied  the  need  for  sending  labled  parameters 
from  a  sensor  to  possibly  several  indicators. 

•  The  bus  was  transmitter  controlled,  i.  e, ,  the  transmitter  sends 
a  data  word  when  the  word  is  available  to  be  sent. 

•  As  in  analog  systems,  the  indicator  was  considered  a  data  sink. 

•  A  complete  data  message  was  contained  in  one  word, 

•  Each  word  had  the  parameter  type  identified  with  a  label. 

•  The  transmission  system  was  fully  defined  to  permit  unit  inter¬ 
changeability  on  the  bus  and  interchangeability  of  units  between 
airplane  types. 

•  The  bus  used  a  single  twisted  shielded  pair  wire  and  employed  a 
RZ  bipolar  modulation  of  the  data, 

•  An  electro-mechanical  indicator  could  not  respond  to  rapid  changes 
in  input  digital  signal,  therefore,  an  error  control  policy  of  rapid 
refresh  of  information  was  adopted. 

The  need  to  look  at  ARINC  575  avionics  for  military  aircraft  originated  with 
the  likelihood  that  the  AMST  will  use  some  commercial  avionics  having  a  575 
interface.  Other  equipment  on  the  AMST  (more  recently  the  C-X)  will  likely 
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use  a  MIL-STD-  1553  interface,  suggesting  the  possibility  of  some  interaction 
^  between  the  two  buses.  If  a  degree  of  direct  interaction  could  be  achieved, 

a  significant  savings  in  special  interface  hardware  could  be  realized  through 
the  use  of  innovative  system  design  and  judicious  software  management. 
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FEASIBILITY  STUDY 


3.  0 

A  comparison  of  the  systems  described  in  the  preceding  section  was  performed 
in  order  to  weigh  the  feasibility  of  effecting  intersystem  compatibility.  This 
task  generally  does  not  attempt  to  define  techniques  or  implementation  methods, 
but  concentrates  in  the  reduction  of  the  accumulated  data  into  a  form  which 
may  be  used  efficiently  in  the  selection  of  integration  techniques. 

This  section  contains  a  description  of  the  methods  employed  to  assess 
integration  feasibility  and  a  presentation  of  the  results  of  the  feasibility  study. 
The  following  specific  areas  of  compatibility  are  discussed: 

•  System  comparison 

•  Message  formats 

•  Mode  control  fields 

•  Mode  codes 

•  Status  word  codes 

•  Message  timing 

•  Cable  characteristics 

•  Basic  signal  characteristics 

3.  1  SYSTEM  COMPARISON 

An  initial  comparison  of  the  systems  described  in  Section  2.0  revealed  that 
the  major  characteristics  of  most  of  these  systems  correspond  to  MIL-STD- 
1553.  In  fact,  an  examination  of  eight  major  bus  characteristics  shows  that 
all  but  two  of  the  systems  exhibit  identical  characteristics  when  examined 
to  this  level.  The  two  exceptions  are  the  F-15  (MDC  H009)  and  the  ARINC 
575  bus.  It  thus  becomes  reasonable  to  refer  to  all  but  these  two  as  1553- 
type  systems  and  list  their  characteristics  as  MIL-STD-  155  3A  /  B.  Table  1 
is  a  summary  of  these  eight  major  characteristics.  While  these 
characteristics  are  common  to  all  1553  type  systems,  it  can  be  seen  that 
H009  and  ARINC  575  busses  differ  in  many  significant  areas.  A  necessary 
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conclusion  is  that  it  is  not  feasible  to  impose  H009  or  ARINC  575  compatibility 
requirements  on  a  1553  type  terminal,  although  some  degree  of  data  inter¬ 
change  would  be  possible  by  the  use  of  an  adapter /formatter  interface  between 
the  two  buses.  Therefore,  the  ARINC  and  F-15  buses  were  not  considered 
for  the  remainder  of  the  feasibility  comparison  of  1553  type  buses,  but  will 
be  the  subject  of  a  separate  consideration  of  adapter /formatter  interface 
techniques.  Since  DAIS  is  compliant  with  1553B,  it  will  not  be  considered  as  a 
separate  system.  This  left  six  systems  to  be  carried  through  the  remainder  of  this 
task.  Theseare  1553A,  1553B,  F-16,  B-52  0AS,  F-18,  and  YAH-64. 

3.2  MESSAGE  FORMATS 

The  next  area  of  consideration  was  that  of  the  message  formats  defined  for 
each  of  the  remaining  systems.  These  formats  are  summarized  in  Table  2. 

It  is  interesting  to  note  that  all  message  formats  are  common  to  1553A, 
which  allows  four  basic  message  formats.  In  addition  to  the  basic  four, 

1553B  defined  the  broadcast  mode,  one  version  of  which  is  implemented 
(though  not  used)  by  the  F-  16  and  the  use  of  a  data  word  in  conjunction  with 
a  mode  command. 

MIL-STD- 1553B  defines  a  number  of  allowable  message  formats  not  defined 
by  previous  revisions.  These  consist  primarily  of  mode  commands  which 
utilize  data  words  and  further  definitions  of  the  use  of  the  optional  broad¬ 
cast  functions.  Message  formats  are  divided  by  1553B  into  two  categories, 
normal  information  transfer  formats  (single  receiver)  and  broadcast  infor¬ 
mation  transfer  formats  (multiple  receivers).  The  broadcast  formats  are 
unique  in  that  they  do  not  require  a  status  response  from  the  receiving 
terminal.  The  message  formats  as  defined  by  1553B  are  illustrated  in 
Figures  7  and  8.  The  command/response  protocol  further  divides 
messages  into  two  types  of  formate:  (a)  data  messages  and  (b)  control 
messages. 
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Mode  Command  Without 
Data  Word  (Broadcast) 


Figure  8  Broadcast  Information  Transfer  Formats  (Multiple  Receivers) 


3.2.  1 


Data  Messages 

Data  messages  are  used  to  communicate  subsystem  data  to  meet  the  objectives 
of  the  mission.  As  in  the  control  messages,  there  are  two  message  types: 
single  receiver  and  multiple  receiver  messages.  These  are  transmitted  in 
the  following  manner: 

Single  Receiver 

•  Bus  controller  to  remote  terminal 

•  Remote  terminal  to  bus  controller 

•  Remote  terminal  to  remote  terminal 

Multiple  Receivers 

•  Bus  controller  to  multiple  remote  terminals 

•  Remote  terminal  to  multiple  remote  terminals 

Each  of  these  messsges  is  transmitted  using  command  and  status  words  for 
control  operation.  The  command  word  is  used  to; 

•  Identify  the  receiving  terminal  (or  signify  broadcast) 

•  Identify  if  data  are  to  be  received  or  transmitted  by  the  receiving 
terminals ) 

•  Identify  the  specific  message  identification  (subaddress)  within  the 
remote  terminals ) 

•  Notify  the  terminals )  of  the  number  of  data  words  to  be  received  or 
transmitted 

The  status  word  is  used  to: 

•  Identify  the  terminal  returning  status 

•  Return  status  information  relative  to  the  terminal  and  subsystem 

The  following  is  a  discussion  of  each  of  the  allowable  data  message  formats, 
with  1553B  being  used  as  a  baseline.  The  single  and  multiple-receiver  data 
message  formats  are  illustrated  in  Figures  9  and  10,  respectively. 
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Figure  9  Single-Receiver  Data  Menage  Formats 


hgure  1 0  Multiple-Receiver  Data  Message  Formats 


3.2.  1.  1 


Bus  Controller  to  Remote  Terminal 


The  bus  controller  issues  a  receive  command  followed  by  the  specified  number 
of  data  words.  After  message  validation  the  RT  transmits  a  status  word  back 
to  the  controller.  The  command  and  data  words  are  transmitted  in  a  contiguous 
fashion  with  no  interword  gaps.  This  format  is  common  to  all  six  systems. 

3.2.  1.2  Remote  Terminal  to  Bus  Controller 

The  bus  controller  issues  a  transmit  command  to  the  Remote  Terminal. 

After  command  word  validation,  the  RT  transmits  a  status  word  back  to  the 
bus  controller,  followed  by  the  specified  number  of  data  words.  The  status 
and  data  words  are  transmitted  in  a  contiguous  fashion  with  no  interword  gaps. 
This  format  is  also  common  to  all  six  systems. 

3.2.  1.3  Remote  Terminal  to  Remote  Terminal 

The  bus  controller  issues  a  receive  command  to  RT  A  followed  contiguously 
by  a  transmit  command  to  RT  B.  After  command  verification  RT  B  transmits 
a  status  word  followed  by  the  specified  number  of  data  words.  The  status  and 
data  words  are  transmitted  in  a  contiguous  fashion  with  no  gap.  At  the 
conclusion  of  the  data  transmission  by  RT  B,  RT  A  transmits  a  status  word 
within  the  specified  time  period.  All  six  systems  utilize  the  RT  to  RT  mode. 

3.2.  1.4  Bus  Controller  to  Remote  Terminals  Broadcast 

The  bus  controller  issues  a  receive  command  word  with  11111  in  the  RT  address 
field  followed  by  the  specified  number  of  data  words.  The  command  word  and 
data  words  are  transmitted  in  a  contiguous  fashion  with  no  gap.  After  message 
validation,  RTs  with  the  broadcast  option  set  the  broadcast  command  received 
bit  in  the  -status  word  but  do  not  transmit  the  status  word.  Although  this  format 
is  implemented  on  the  F-16  hardware,  it  is  not  presently  used.  Note  that 
broadcast  formats  are  prohibited  for  new  AF  avionics  use  by  MIL-STD-1553B 
Notice  1  (USAF)  (see  Section  4.2). 


3.2.  1.5 


Remote  Terminal  to  Remote  Terminals  Broadcast 


The  bus  controller  issues  a  receive  command  word  with  11111  in  the  RT 
address  field  followed  by  a  transmit  compnand  to  RT  A  using  the  RT's 
address.  After  command  word  validation,  RT  A  transmits  a  status  word 
followed  by  the  specified  number  of  data  words.  The  status  and  data  words 
are  transmitted  in  a  contiguous  fashion  with  no  gap.  After  message  validation, 
RTs  with  the  broadcast  option,  excluding  RT  A,  set  the  broadcast  received 
bit  in  the  status  word  but  do  not  transmit  the  status  word.  RT  to  RT  broad¬ 
cast  is  not  used  by  any  of  the  systems  represented. 

3.2.2  Control  Messages 

Control  messages  consist  of  Mode  Commands  and  may  or  may  not  include 
a  single  associated  data  word.  Mode  commands  are  used  to  manage  the  data 
bus  system  and  are  considered  a  necessary  overhead  requirement  to  properly 
control  the  data  flow.  The  overhead  requirements  are  provided  by  command 
words  and  status  words.  These  header  words  to  each  data  transmission  are 
required  to  maintain  data  flow  within  the  multiplex  system.  Command 
and  status  words  are  associated  with  both  control  messages  and  data  messages. 
Message  formats  within  this  protocol  can  be  transmitted  to  a  single  receiver 
or  to  multiple  receivers  based  upon  the  command  word  address  for  the 
message. 

Mode  commands  are  identified  by  the  subaddress /mode  field  in  the  command 
word  being  set  to  32  (00000)  or  31  (11111).  All  control  messages  originate 
with  the  bus  controller  and  are  received  by  a  single  receiver  or  by  multiple 
receivers  (broadcast).  The  mode  code  information  is  in  the  word  count/mode 
code  field  of  the  command  word  and  in  the  attached  data  word  if  allowed  by 
the  mode  code. 
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The  various  legal  mode  codes  without  and  with  data  word  are  illustrated 
in  Figure  11. 

3.2.2.  1  Mode  Command  Without  Data  Word 

The  bus  controller  issues  a  transmit  command  to  the  RT  containing  a  specified 
mode  code.  After  command  word  validation,  the  RT  transmits  a  status  word. 
This  format  is  implemented  in  all  six  systems. 

3.  2.  2.  2  Mode  Command  With  Data  Word  (Transmit) 

The  bus  controller  issues  a  transmit  command  to  the  RT  using  a  specified 
mode  code.  After  command  word  validation,  the  RT  transmits  a  status  word 
followed  by  one  data  word.  The  status  word  and  data  word  are  transmitted  in 
a  contiguous  fashion  with  no  gap.  This  command  is  not  used  by  any  of  the 
candidate  systems. 

3.  2.  2.  3  Mode  Command  With  Data  Word  (Receive) 

The  bus  controller  issues  a  receive  command  to  the  RT  using  a  specified 
mode  code,  followed  by  one  data  word.  The  command  word  and  data  word 
are  transmitted  in  a  contiguous  fashion  with  no  gap.  After  command  and  data 
word  validation,  the  RT  transmits  a  status  word  back  to  the  controller.  This 
command  is  not  used  by  any  of  the  candidate  systems. 

3.  2.  2.  4  Mode  Command  Without  Data  Word  Broadcast 

The  bus  controller  issues  a  transmit  command  word  with  11111  in  the  RT 
address  field,  00000  or  11111  in  the  subaddress  field,  and  a  specified 
mode  code  in  the  word  count/mode  code  field.  After  command  validation, 

RTs  with  the  broadcast  option  set  the  broadcast  received  bit  in  the  status 
word  but  do  not  transmit  the  status  word.  This  command  is  not  used  by  any 
of  the  candidate  systems. 
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Modi  Command  Without  Data  Wold  to  a  Single  Receiver 


* 


Source:  but  controller  Source:  tingle  receiver 


MODE 

COMMAND 


STATUS 

RESPONSE 


□ 


Transmit  Mode  Command  With  Data  Word  to  a  Single  Receiver 


MODE 

COMMAND 

* 

STATUS 

RESPONSE 

I 

DATA  WORD 

Source:  but  controller 


Source:  tingle  receiver  Mode  data  response 


Receive  Mode  Command  With  Data  Word  to  a  Single  Receiver 


MODE 

COMMAND 

DATA  WORD 

* 

STATUS 

RESPONSE 

Source:  but  controller 

Mode  data  word 

Source:  single  receiver 

Trammit  Mode  Command  Without  Data  Word  to  Multiple  Receivers 


MODE 

COMMAND 


Source:  but  controller 


□ 


T ransmit  Mode  Command  With  Date  Word  to  Multiple  Receivers 


MODE 

COMMAND 


DATA  WORD 
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Sourct  but  controller 


Mode  data  word 
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3.2.2.  5 


Mode  Command  With  Data  Word  Broadcast 


The  bus  controller  issues  a  receive  command  with  11111  in  the  RT  address 
field,  00000  or  11111  in  the  subaddress  field,  and  a  specified  mode  code  in 
the  word  count/mode  code  field,  followed  by  one  data  word.  The  command 
word  and  data  word  are  transmitted  in  a  contiguous  fashion  with  no  gap. 

After  message  validation,  RT  s  with  the  broadcast  option  set  the  broadcast 
received  bit  in  the  status  word  but  do  not  transmit  the  status  word.  This 
command  is  not  used  by  any  of  the  candidate  systems. 

3.  3  MODE  CONTROL  FIELD 

Data  gathered  on  the  candidate  systems  revealed  several  incompatibilities  in  the 
structure  of  the  command  word.  The  first  of  these  encountered  is  the  sub¬ 
address/mode  control  field.  MIL-STD- 1553A  specified  all  zeroes  as  the  mode 
control  code.  As  shown  in  Table  3,  this  code  i6  used  by  all  but  the  F-16 
which  uses  all  ones.  MIL-STD- 1553B,  however,  allows  either  all  ones  or 
all  zeroes.  The  use  of  the  mode  control  code  in  the  subaddress  field  implies 
that  the  word  count  field  contains  mode  control  data  rather  than  word  count. 

The  use  of  this  field  in  transmitting  control  information  was  described  in 
Section  3.  2. 

3.4  MODE  CODES 

The  basic  philosophy  of  the  MIL-STD- 1553  information  transfer  system  is  that 
it  operates  as  a  transparent  communication  link.  "Transparent'  means  that 
an  application's  function  does  not  need  to  be  involved  with  the  management  of 
communication  control.  Obviously,  the  information  transfer  system  requires 
management  that  introduces  overhead  into  the  transmission  of  data.  The 
command  words,  status  words,  status  word  gaps,  and  message  gaps  are  the 
overhead.  Within  the  command  word,  the  mode  codes  provide  data  bus 
management  capability.  The  mode  codes  have  been  divided  into  two  groups: 
mode  codes  without  a  data  word  (00000  -  01111)  and  mode  codes  with  a  data 


Table  3 

Command  Word 


Mode  Control  {Subaddress  Field) 


MIL-STD-  1553B 
MIL-STD-  1553A 
F- 16 

B- 52  O AS 
F- 18 
YAH-64 


00000  11111 

X  X 

X 


X 

X 

X 


I 


j 


4 

I 


word  (10000  -  11111).  The  use  of  bit  15  in  the  command  word  to  identify  the 
two  types  was  provided  to  aid  in  the  decoding  process.  Also,  the  use  of  a 
single  data  word  instead  of  multiple  data  words  was  adopted  to  simplify  the 
mode  circuitry.  Generally,  with  these  two  types  of  mode  commands,  all 
management  requirements  of  an  information  transfer  system  can  be  met. 

Control  messages  are  identified  by  the  subaddress -mode  field  in  the  command 
word  being  set  to  32  (00000)  or  31  (11111).  (In  this  case,  1553B  defines 
decimal  subaddress  32  to  be  equal  to  binary  00000  so  that  decimal  1  through 
decimal  31  correspond  to  binary  00001  through  11111).  All  control  messages 
originate  with  the  active  bus  controller  and  are  received  by  a  single  receiver 
or  by  multiple  receivers  (broadcast).  A  terminal  address  value  of  31  (11111) 
in  the  command  word  indicates  a  broadcast  message,  while  any  other  terminal 
addresses  are  to  identify  unique  messages  to  a  terminal  on  the  bus.  The  mode 
code  information  is  contained  completely  in  the  word  count/mode  code 
field  of  the  command  word. 

The  symmetry  of  the  mode  codes  is  important  to  system  design.  The  first 

16  codes  are  not  transmitted  with  a  data  word;  the  last  16  are.  It  is  not 
appropriate  to  broadcast  some  of  the  mode  codes  because  of  the  possibility 
of  bus  crashes  -  simultaneous  transmission  by  two  or  more  terminals. 
Examples  are  requests  for  transmissions  from  RTs.  Also,  broadcast  of 
dynamic  bus  control  makes  no  sense.  The  T/R  bit  is  important  for  mode  codes 

17  to  31  because  it  defines  whether  bus  controller  or  RT  is  to  transmit  the 
associated  data  word. 

The  use  of  the  mode  commands  option  is  defined  in  both  versions  of  the 
standard;  however,  1553B  defines  each  mode  code  while  1553A  only  defines 
dynamic  bus  control.  There  is  no  particular  reason  for  the  assignment  of  the 
mode  codes,  except  for  dynamic  bus  control  (00000),  which  was  previously 
defined  in  1553A,  and  the  separation  of  mode  codes  by  their  use  of  a  data 
word.  The  purpose  of  reserved  mode  codes  in  each  category  (with  and 


without  data  words)  is  important  to  allow  for  controlled  expansion  of  the 
standard.  By  controlling  the  mode  code  number  and  its  definition, 
commonality  between  various  terminals  can  be  maintained.  Each  mode  code 
identification  defined  by  1553B  is  listed  in  Table  4.  All  other 
mode  codes  are  considered  illegal, 

3.4.1  Dynamic  Bus  Control 

i 

The  dynamic  bus  control  mode  code  (00000)  is  provided  to  allow  the  active 
bus  controller  a  mechanism  (using  the  information  transfer  system  message 
formats)  to  offer  a  potential  bus  controller  (operating  as  a  remote  terminal) 
control  of  the  data  bus.  Only  the  single  receiver  command  request  (unique 
address)  is  allowed  to  be  issued  by  the  active  bus  controller.  The  response 
to  this  offering  of  bus  controller  is  provided  by  the  receiving  remote  terminal 
using  the  dynamic  bus  control  acceptance  bit  in  the  status  word.  Rejection  of 
this  request  by  the  remote  terminal  requires  the  presently  active  bus 
controller  to  continue  offering  control  to  other  potential  controllers  or  remain 
in  control.  When  a  remote  terminal  accepts  control  of  the  data  bus  system 
by  setting  the  dynamic  bus  control  acceptance  bit  in  the  status  word,  control 
is  relinquished  by  the  presently  active  bus  controller,  and  the  potential  bus 
controller  begins  bus  control. 

Note  that  the  sequence  above  requires  software  (or  firmware)  implementation 
in  all  bus  controllers. 

3.4.2  Synchronize 

Synchronization  informs  the  terminals )  of  an  event  time  to  allow  coordination 
between  the  active  bus  controller  and  receiving  terminals.  Synchronization 
information  may  be  implicit  in  the  command  word  (mode  code  00001)  or  a 
data  word  (mode  code  10001)  may  be  used  to  follow  the  command  word  to 
provide  the  synchronization  information.  If  a  data  word  is  used,  the 
definition  of  the  bit  meanings  is  the  responsibility  of  the  system  designer. 


Table  4  MID-STD-1553B  Defined  Mode  Codes 


Transmit* 

receive 

Mode  code 

Function 

Associated 
data  word 

Broadcast 

command 

allowed 

T 

00000 

Dynamic  but  control 

No 

No 

T 

00001 

Synchronize 

No 

Yes 

T 

00010 

Transmit  status  word 

No 

No 

T 

00011 

Initiate  sell-test 

No 

Yes 

T 

00100 

T ransmitter  shutdown 

No 

Yes 

T 

00101 

Override  transmitter  shutdown 

No 

Yes 

T 

00110 

Inhibit  terminal  flag  bit 

No 

Yes 

T 

00111 

Override  inhibit  terminal  flag  bit 

No 

Yes 

T 

01000 

Reset  remote  terminal 

No 

Yes 

T 

01001 

4 

Resjrved 

No 

i 

TBO 

4 

T 

01111 

Reserved 

Jo 

TBD 

T 

10000 

Transmit  vector  word 

Yes 

No 

R 

10001 

Synchronize 

Yes 

Yes 

T 

10010 

Transmit  last  command 

Yes 

No 

T 

10011 

Transmit  bit  word 

Yes 

No 

R 

10100 

Selected  transmitter  shutdown 

Yes 

Yes  ' 

R 

10101 

Override  selected  transmitter  snutdown 

Yes 

Yes 

TBO 

10110 

Reserved 

Yes 

TBD 

TBD 

lllll 

Reserved 

l 

tId 

Note:  TBO— to  be  determined. 

x. 

x 
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3.4.  3 


Transmit  Status  Word 


The  status  word  associated  with  mode  code  (00010)  contains  the  following 
information: 

•  Terminal  Address 

•  Message  Error  bit 

•  Instrumentation  bit 

•  Service  Request  bit 

•  Broadcast  Command  Received  bit 

•  Busy  bit 

•  Subsystem  Flag  bit 

•  Dynamic  Bus  Control  Acceptance  bit 

•  Terminal  Flag  bit 

•  Reserved  bits  (3) 

Details  concerning  the  usage  of  the  status  bits  are  discussed  in  1553B.  The 
only  message  format  for  acquiring  the  status  word  using  this  mode  code  is  for 
the  bus  controller  to  request  the  status  word  from  a  single  receiver.  Note 
that  use  of  this  mode  code  by  the  bus  controller  causes  the  last  status  word  to 
be  transmitted.  Some  subtle  conditions  need  to  be  examined  by  the  designer 
who  uses  this  request.  For  example,  if  the  last  command  word  is  needed  to 
verify  that  it  was  indeed  received  by  an  RT,  that  request  must  be  transmitted 
first,  since  the  RT  will  only  "save"  the  last  command  from  the  bus  controller. 
Therefore,  if  "transmit  status  word"  is  sent  before  "transmit  last 
command  word,  "  the  last  command  saved  by  the  RT  will  be  "transmit  status 
word". 

3.4.4  Initiate  Self  Test 

The  initiate  self -test  mode  code  (00011)  is  provided  to  initiate  Built-In-Test 
(BIT)  circuitry  within  remote  terminals.  The  mode  code  is  usually  followed, 
after  sufficient  time  for  test  completion,  by  a  transmit  BIT  word  mode 
command  yielding  the  results  of  the  test.  The  message  formats  provided  for 
this  mode  code  allow  for  both  individual  requests  and  multiple  request. 
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Notice  that  the  initiate  self-test  mode  code  is  associated  with  the  multiplex 
system  terminal  hardware  only. 

3.4.5  Transmit  Built-In-Test  (BIT)Word 

The  transmit  BIT  word  mode  code  (10011)  provides  the  BIT  results 
available  from  a  terminal,  as  well  as  the  status  word.  Typical  BIT  word 
information  for  both  embedded  and  standalone  remote  terminals  includes 
encoder-decoder  failure,  analog  T/R  failures,  terminal  control  circuitry 
failures,  power  failures,  subsystem  interface  failures,  and  protocol  errors 
(e.  g.  ,  parity,  Manchester,  word  count,  status  word  errors,  and  status  word 
exceptions).  The  internal  contents  of  the  BIT  data  word  are  provided  to 
supplement  the  appropriate  bits  already  available  via  the  status  word  for 
complex  terminals.  Notice  that  the  BIT  word  within  the  remote 
terminal  "...  shall  not  be  altered  by  the  reception  of  a  transmit  last  command 
or  transmit  status  word  mode  code"  received  by  the  terminal.  This  allows 
error  handling  and  recovery  procedures  to  be  used  without  changing  the  error 
data  recorded  in  this  word.  However,  the  RT  will  only  save  the  last  command, 
and  the  status  code  field  (of  the  status  word)  will  not  be  changed  if  transmit 
last  command  or  transmit  status  word  mode  codes  are  transmitted.  If, 
however,  any  other  transmissions  are  made  to  the  RT,  the  status  code  field 
may  change  (e.  g.  ,  if  a  message  error  occurred  during  the  transmission). 
Broadcast  of  this  code  by  the  bus  controller  is  not  allowed. 

3.4.6  Transmitter  Shutdown 

Four  mode  codes  are  provided  to  control  transmitters  associated 

with  terminals  in  a  system.  These  codes  can  be  sent  to  a  single  receiver 

or  broadcast  to  multiple  users. 

The  transmitter  shutdown  mode  code  (00100)  is  used  in  a  dual -redundant  bus 
structure  where  the  code  causes  the  transmitter  associated  with  the  other 
redundant  bus  to  terminate  transmissions.  No  data  word  is  provided  for  this 
code. 


3.4.  7 


Override  Transmitter  Shutdown 


The  override  transmitter  shutdown  mode  code  (00101)  is  used  in  a  dual- 
redundant  bus  structure  where  the  code  allows  the  transmitter  previously- 
disabled  associated  with  the  redundant  bus  to  transmit  when  commanded  by  a 
normal  bus  command  initiated  by  the  active  bus  controller.  No  data  word  is 
provided  for  this  mode  code. 

1 

•  3.4.8  Selected  Transmitter  Shutdown 

The  selected  transmitter  shutdown  mode  code  (10100)  is  used  in  a  multiple 
(greater  than  two)  redundant  bus  structure  where  the  code  causes  the 
selected  transmitter  to  terminate  transmissions  on  its  bus.  A  data  word  is 
used  to  identify  the  selected  transmitter. 

3,4,9  Override  Selected  Transmitter  Shutdown 

The  override  selected  transmitter  shutdown  mode  code  (10101)  is  used  in  a 
multiple  (greater  than  two)  redundant  bus  structure  where  the  code  allows 
the  selected  transmitter  to  transmit  on  its  bus  when  commanded  by  a  normal 
bus  command  initiated  by  the  active  bus  controller.  A  data  word  is  used  to 
identify  the  selected  transmitter. 

3.  4,  1 0  Inhibit  Terminal  Flag 

The  inhibit  terminal  flag  mode  code  (00110)  is  used  to  set  the  terminal  flag 
bit  in  the  status  word  to  an  unfa iled  condition  regardless  of  the  actual  state 
of  the  terminal  being  addressed.  This  mode  code  is  primarily  used  to 
prevent  continued  interrupts  to  the  error  handling  and  recovery  system  when 
the  failure  has  been  noted  and  the  system  reconfigured  as  required. 

Sending  this  mode  code  prevents  future  failures  from  being  reported, 
which  normally  would  be  reported  using  the  terminal  flag  in  each  subsequent 
status  word  response.  The  message  format  associated  with  the  mode  code 
allows  for  both  single  receivers  and  multiple  receivers  to  respond.  No  data 
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word  is  required  with  this  mode  code.  Note  that  the  terminal  flag,  which  is 
used  to  Indicate  an  RT  fault  condition  is  implicitly  limited  to  terminal  faults. 

3.4.11  Override  Inhibit  Terminal  Flag 

The  Override  inhibit  T/F  flag  mode  code  (00111)  negates  the  inhibit 
function  thus  allowing  the  T/F  flag  bit  in  the  status  response  to  report  present 
condition  of  the  terminal.  This  mode  code  can  be  transmitted  by  the  active 
bus  controller  to  both  single  and  multiple  receivers.  There  is  no  data  word 
associated  with  this  mode  code. 

3.4.12  Reset  Remote  Terminal 

The  reset  remote  terminal  mode  code  (01000)  causes  the  addressed  terminal 
to  reset  itself  to  a  power-up  initialized  state.  This  mode  code  may  be  trans¬ 
mitted  to  an  individual  or  to  multiple  terminals. 

3.4.13  Transmit  Vector  Word 

The  transmit  vector  word  mode  code  (10000)  is  associated  with  the  service 
request  bit  in  the  status  word  and  is  used  to  determine  specific  service  being 
required  by  the  terminal.  The  service  request  bit  and  the  transmit  vector 
word  provide  the  only  means  available  for  the  terminal  to  request  the 
scheduling  of  an  asynchronous  message.  The  message  format  for  this  single 
receiver  operation  contains  a  data  word  associated  with  the  terminal's  response 

3.4.  14  Transmit  LaBt  Command  Word 

The  transmit  last  command  mode  code  (10010)  is  used  in  the  error  handling 
and  recovery  process  to  determine  the  last  valid  command  received  by  the 
terminal,  except  for  this  mode  code.  Also  this  mode  code  will  not  change 
the  state  of  the  status  word.  The  message  format  associated  with  the  single 
receiver  last  command  word  contains  a  data  word  from  the  responding 
terminal.  The  data  word  contains  the  previous  16  bits  of  the  last  valid 
command  word  received.  Notice  that  this  mode  code  will  not  alter  the 
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state  of  the  receiving  terminals  status  word.  This  fact  allows  this  mode 
code  to  be  used  in  error  handling  and  recovery  operation  without  affecting 
the  status  word,  which  can  have  added  error  data. 


3.4.15  Reserved  Mode  Codes 

Each  of  the  mode  code  types  (with  and  without  data  words)  have  several  unused 
mode  codes  that  are  reserved  for  future  use  and  cannot  be  used  without  the 
permission  of  the  Military  Standard's  Controlling  Agency. 

3.4.16  Candidate  System  Mode  Codes 

Table  5  lists  mode  code  assignments  for  the  six  systems.  The  F-18 
specification  (MDC  A3818)  reserves  the  all  zeroes  code  for  dynamic  bus 
allocation  per  1553A  but  leaves  the  others  to  the  discretion  of  the  individual 
RT  design.  This  implies  that  different  mode  codes  may  be  assigned  to 
different  F-18  remote  terminals. 

The  F-16  utilizes  only  one  unique  mode  code.  The  code  00001  is  a  reset 
timer  code.  Any  other  code  is  interpreted  as  a  transmit  status  code. 

3.  5  STATUS  WORD  CODES 

Status  word  code  assignments  also  vary  among  the  seven  systems.  Only  the 
message  error  and  terminal  flag  bits  were  assigned  by  1553A.  1553B, 

however,  made  additional  status  code  assignments.  The  status  word  is  part 
of  the  basic  overhead  requirements  of  the  data  bus  system.  The  status  word 
as  defined  by  1553B  is  shown  in  Figure  12  and  is  divided  into  the  following 
fields : 

•  Sync  (same  as  command  sync) 

•  Terminal  Address 
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Figure  12  Status  Word 


•  Status  field 

e  Parity  (P) 

The  five-bit  address  field  identifies  the  transmitting  terminal’s  address,  while 
the  remote  terminal's  status  is  based  on  bits  set  in  the  status  field.  The 
status  field  consists  of  the  following  information: 

e  Message  Error  bit 

e  Instrumentation  bit 

e  Service  Request  bit 

e  Reserved  field  (3  bits) 

e  Broadcast  Command  Received  bit 

e  Busy  bit 

e  Subsystem  Flag  bit 

e  Dynamic  Bus  Control  Acceptance  bit 

e  T  erminal  Flag  bit 

3.5.1  Message  Error  Bit 

The  message  error  bit  is  set  to  logic  one  to  indicate  that  one  or  more  of  the 
data  words  associated  with  the  preceding  received  message  has  failed  to  pass 
the  message  validity  test.  The  message  validity  requirements  are: 

•  Word  validation  -  word  begins  with  valid  sync,  Manchester  II  code 
correctly  transmitted,  16  data  bits  plus  parity,  and  word  parity  odd 

e  Contiguous  words  within  a  message 

e  Address  validation  -  matches  unique  terminal  address  or  broadcast 

address 

e  Legal  command  -  a  terminal  with  the  illegal  command  detection 

circuitry  does  not  detect  an  illegal  command 

The  status  word  will  be  transmitted  if  the  message  validity  requirements  are 
met.  When  a  message  error  occurs  in  a  broadcast  message  format,  the 
message  error  bit  will  be  set  in  the  status  word  and  the  status  response  with- 
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held  as  required  by  broadcast  message  format. 

3.5.2  Instrumentation  Bit 

The  optional  instrumentation  bit  in  the  status  field  is  used  to  distinguish  the 
status  word  from  the  command  word.  Since  the  sync  field  (three  bits)  is  used  to 
distinguish  the  command  and  status  words  from  a  data  word,  a  mechanism  to 
distinguish  command  and  status  is  provided  by  the  instrumentation  bit.  By  setting 
this  bit  to  logic  zero  for  all  conditions  and  setting  the  same  bit  position  in  the 
command  word  to  a  logic  one,  the  command  and  status  words  are  identifiable. 

If  used,  this  approach  reduces  the  possible  subaddresses  in  the  command  word 
to  15  and  requires  subaddress  31  (11111)  to  be  used  to  identify  mode  commands 
(both  31  and  32  are  allowed).  The  bit  will  remain  set  to  logic  zero  in  the 
status  word  for  all  conditions,  whether  or  not  this  option  is  used. 

3.5.3  Service  Request  Bit 

The  service  request  bit  is  provided  to  indicate  to  the  active  bus  controller 
that  a  remote  terminal  requests  service.  When  this  bit  in  the  status  word  is 
set  to  logic  one,  the  active  bus  controller  may  take  a  predetermined  action, 
or  use  a  mode  code  (e.  g.  transmit  vector  word)  to  identify  the  specific  request. 

3.5.4  Reserved  Status  Bits 

This  three  bit-field  (12-14)  is  reserved  for  future  requirements  and  is  set 
to  logic  zero. 

3.  5.  5  Broadcast  Command  Received  Bit 

The  broadcast  command  received  bit  is  set  to  logic  one  when  the  preceding 
valid  command  word  was  a  broadcast  command  (address  31).  Since  broadcast 
message  formats  require  the  receiving  remote  terminals  to  suppress  their 
status  words,  the  broadcast  command  received  bit  is  set  to  identify  that  the 
command  was  received  properly.  The  broadcast  command  received  bit  will 
be  reset  when  the  next  valid  command  is  received  by  the  remote  terminal. 
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unless  the  next  valid  command  is  transmit  status  word  or  transmit  last 
command. 

3.5.6  Busy  Bit 

The  busy  bit  in  the  status  word  is  set  to  logic  one  to  indicate  to  the  active  bus 
controller  that  the  remote  terminal  is  unable  to  move  data  to  or  from  the  sub¬ 
system  in  compliance  with  the  bus  controller's  command.  A  busy  condition 
can  exist  within  a  remote  terminal  at  any  time  causing  it  to  be  nonresponsive 
to  a  command  to  send  data  or  to  be  unable  to  receive  data.  This  condition 
can  exist  for  all  message  formats.  In  each  case  except  the  broadcast 
message  formats,  the  active  bus  controller  will  determine  the  busy  condition 
immediately  upon  status  response.  ”  In  the  case  of  the  broadcast  message 
formats,  this  information  will  not  be  known  unless  the  receiving  terminals 
are  polled  after  the  broadcast  message  requesting  their  status.  If  the  status 
word  has  the  broadcast  received  bit  set,  the  message  was  received  and  the 
terminal  was  not  busy. 

3.  5.  7  Subsystem  Flag  Bit 

The  subsystem  flag  bit  is  provided  to  indicate  to  the  active  bus  controller 
that  a  subsystem  fault  condition  exists  and  that  data  being  requested  from 
the  subsystem  may  be  invalid.  The  subsystem  flag  may  be  set  in  any  trans¬ 
mitted  status  word. 

3.  5.  8  Dynamic  Bus  Control  Acceptance  Bit 

This  bit  is  provided  to  indicate  the  acceptance  of  the  offer  by  the  active 
bus  controller  to  become  the  next  bus  controller.  The  offer  of  bus 
control  occurs  when  the  presently  active  bus  controller  has  completed  its 
established  message  list  and  issues  a  dynamic  bus  control  mode  command  to 
the  remote  terminal  that  is  to  be  the  next  potential  controller.  To  accept  the 
offer  the  potential  bus  controller  sets  its  dynamic  bus  control  acceptance  bit 
in  the  status  word  and  transmits  the  status  word. 
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3.5.9  Terminal  Flag  Bit 

The  terminal  flag  bit  is  set  to  a  logic  one  to  indicate  a  fault  within  the  remote 
terminal.  This  bit  is  used  in  connection  with  three  mode  code  commands: 

•  Inhibit  T/F  Flag 

e  Override  Inhibit  T/F  Flag 

e  Transmit  BIT  Word 

The  first  two  above  mode  codes  deactivate  and  activate  the  functional 
operation  of  the  bit.  The  transmit  BIT  word  mode  code  is  used  to 
acquire  more  detailed  information  about  the  terminal's  failure. 

3.5.10  Candidate  System  Status  Codes 

The  status  word  code  assignments  for  the  six  candidate  systems  are  shown 
in  Table  6.  The  message  error  and  terminal  flag  bits  were  assigned  by 
1553A  and  so  are  common  to  all  systems.  Other  status  codes,  however, 
were  assigned  by  individual  system  specifications  and  so  are  not  common. 

3.6  MESSAGE  TIMING 

Although  the  message  formats  used  by  the  seven  candidate  systems  are 
essentially  identical,  certain  aspects  of  message  timing  and  BER  character¬ 
istics  differ  enough  to  have  some  degree  of  hardware  impact.  Some  of  the 
basic  message  timing  characteristics  are  shown  in  Table  7.  Here  again, 
most  of  the  differing  system  parameters  fall  within  the  relaxed  requirements 
of  1553B.  Primary  exceptions  include  the  minimum  message  gap,  which  was 
not  specified  by  1553A,  and  the  response  time. 

3.  6.  1  Response  Time 


The  response  time  of  2-5  usee  is  common  to  all  systems  except  1553B.  The 
response  time  is  different  in  1553B  for  two  reasons:  (1)  the  response  time 
was  increased  by  100%  and  (2)  a  new  measurement  technique  is  used  by  1553B. 
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The  response  time  was  increased  to  4  to  12  usee  by  1553B  to  allow  more 
hardware  design  flexibility  in  the  multiplex  interface  area.  Since  the  measure¬ 
ment  technique  was  undefined  in  1553A  and  because  it  is  hard  to  determine 
when  the  multiplex  line  is  quiet,  1553B  specified  the  response  time  as 
measured  between  the  previous  midbit  (zero)  crossing  and  the  next  midbit  ' 
crossing.  This  measurement  technique  is  illustrated  in  Figure  13.  Note 
that  this  technique  adds  half  the  bit  time  of  the  previous  parity  bit  (1/2  usee) 
and  half  the  bit  time  of  the  next  sync  pattern  (1  1/2  usee)  to  the  time  normally 
obtained  by  measuring  bus  dead  time.  This  results  in  a  total  of  2  usee  being 
added  as  a  result  of  the  new  measurement  technique.  Thus  the  new  4  to  12 
usee  response  time  is  equivalent  to  2  to  10  usee  measured  by  the  old  method, 
giving  an  actual  increase  of  100%. 

3.6.2  Transmitter  Time  Out 

This  is  a  terminal  fail-eafe  feature  which  prevents  an  excessive  transmission 
on  the  data  bus  by  a  single  transmitter.  It  was  originally  defined  by  1553A 
as  660  usee,  the  maximum  allowable  length  of  a  1553  message.  This  require¬ 
ment  was  relaxed  by  the  F-16  and  subsequently  by  1553B  to  allow  less 
accurate  analog  or  relaxed  digital  timers  with  more  independence  of  the  timer 
circuits  to  be  used  in  the  current  design.  MIL-STD-  1553B  presently  allows 
800  usee. 

3.  6.  3  No  Response  Time  Out 

This  is  a  new  requirement  added  by  1553B  to  clarify  the  minimum  time  that 
a  bus  controller  shall  wait  before  concluding  that  the  RT  is  not  going  to 
respond  as  requested.  It  is  defined  by  the  same  measurement  technique 
used  for  the  response  time.  This  parameter  was  not  specified  for  most  of 
the  systems,  ft  poses  a  problem  only  when  a  bus  controller  is  specified 
with  a  shorter  time  out  than  a  user  RT.  For  example,  an  F-18  bus  controller 
which  times  out  in  6.  5  usee  may  not  be  compatible  wi£h  a  1553B  RT  which 
can  wait  up  to  14  usee  before  responding. 
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3.  6.  4  Minimum  Message  Gap 

The  minimum  message  gap  expands  the  requirements  of  the  response  time  in 
1553B.  The  purpose  of  this  requirement  is  to  clearly  show  that  the  buB 
controller  must  leave  a  gap  between  messages  and  that  the  maximum  response 
time  of  12  usee  does  not  apply  to  gaps  between  messages.  Since  gaps  may  be 
greater  than  4  usee,  both  systems  which  specify  this  parameter  are  in 
compliance  with  1553B. 

3.6.5  Error  Rate 

The  bit  error  rate,  word  error  rate  and  message  error  rate  are  three 
different  means  of  specifying  essentially  the  same  parameter.  The  error  rate 
is  a  noise  rejection  specification  and  is  the  maximum  error  rate  allowed  under 
specified  noise  conditions.  MIL-STD-  1553A,  as  well  as  several  of  the  other 
candidate  systems,  specified  bit  error  and  message  error  rates.  Assurance 
that  this  requirement  is  met,  however,  requires  extensive  system-type 
evaluation  testing  of  the  terminal  employing  a  bus  controller  and  data  bus 
radiated  with  certain  of  the  EMI  fields  specified  in  MIL-STD-461  and  462. 
Extensive  test  time  is  required  to  verify  a  BER  of  10"  and  the  test  must  be 
performed  in  a  screen  room. 

The  test  conditions  of  signal  and  noise  specified  in  1553B  were  selected  to 
produce  a  corresponding  value  of  word  error  rate  (WER)  which  is  sufficiently 

_7 

high  (10  )  to  permit  performance  verification  of  a  terminal  receiver  within  a 

reasonable  test  period.  The  noise  rejection  is  a  figure-of-merit  test  and  can 
be  performed  in  a  normal  laboratory  environment  using  actual  transmitters 
(Manchester  waveform  output)  with  a  relatively  simple  test  setup. 

3.7  CABLE  CHARACTERISTICS 

Specified  cable  characteristics  for  the  six  candidate  systems  were  found  to 
differ  only  slightly  as  shown  in  Table  8.  Variations  here  were  minor, 
however,  most  parameters  being  close  enough  to  be  compatible  in  a  practical 
situation. 
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3.8 


BASIC  SIGNAL  CHARACTERISTICS 


Another  aspect  of  the  various  systems  investigated  is  the  basic  electrical 
characteristics  of  the  data  bus  signal  itself.  Here  again,  although  a  degree  of 
variation  was  found,  especially  in  the  signal  levels,  practical  compatibility 
does  not  appear  to  pose  a  serious  problem.  As  is  the  case  with  other  para¬ 
meters,  some  of  the  signal  characteristics  have  been  more  clearly  defined 
by  1553B.  The  basic  signal  characteristics  of  the  candidate  systems  are 
shown  in  Table  9. 

3.8.1  Output  Level 

The  allowable  output  voltages  vary  widely  among  the  six  systems,  ranging 
from  a  low  of  less  than  three  volts  to  an  upper  limit  of  36  volts  peak-to-peak. 

The  upper  end  of  the  bus  voltage  range  (20V  p-p)  allowed  by  1553A  was 
considered  to  be  excessive  and  if  implemented  would  result  in  excessive 
power  dissipation.  Most  of  the  systems  and  hardware  designed  to  1553A 
use  signal  levels  at  or  near  the  lower  end  (6.0V  p-p)  of  the  specified  range. 

It  should  be  noted  that  the  measurement  point  in  1553A  is  at  the  main  bus 
itself.  This  does  not  provide  a  specified  level  at  the  terminal  connection 
point  and  is  especially  troublesome  to  the  terminal  hardware  designer  since 
the  characteristics  of  the  coupler  transformer  are  not  specified.  The  approach 
taken  for  1553B  is  to  specify  the  terminal  output  for  the  two  conditions, 
transformer-coupled  and  direct-coupled.  This  usually  requires  that  each 
terminal  have  two  sets  of  input-output  pins  for  each  bus  cable  connection. 
Therefore,  the  18V  to  27V  p-p  transmitter  output  applied  to  the  stub  and 
coupler  results  in  a  nominal  6.  0V  to  9.  0V  p-p  signal  level  at  the  stub  and  bus 
connection.  This  range  is  equivalent  to  that  specified  for  the  direct-coupled 
case.  Test  configurations  are  provided  for  both  direct- coupled  and  transformer- 
coupled  configurations  by  1553B. 


3.8.2 


Input  Response  Level 


The  input  voltage  specifications  in  1553B  have  been  revised  to  reflect  the 
output  voltage  ranges  for  the  transformer-coupled  and  direot-coupled 
connections  to  the  terminal.  The  terminal-required  response  and  no-response 
signal  levels  are  specified  so  that  the  optimum  threshold  levels  may  be 
selected.  It  should  be  noted  that  the  threshold  setting  has  a  significant 
effect  on  the  noise  rejection  and  error  rate  performance  of  the  receiver.  The 
maximum  value  for  no-response  signal  level  is  200  mV  p-p,  (transformer-coupled), 
ana  280  mV  p-p  (direct-coupled),  thus  allowing  optimum  threshold  settings  of 
+  125  and  175  mV,  respectively,  for  minimum  bit  error  rate  (BER)  performance 
when  subjected  to  the  specified  noise  rejection  test  conditions.  Thus  while 
input  response  levels  may  be  compatible  in  most  cases,  the  noise  rejection/BER 
performance  may  be  out  of  specification  when  hardware  is  mixed  between  systems. 

3.8.3  Waveform  Rise/Fall  Time 

The  transmitted  waveform  specified  in  1553A  is  limited  in  the  definition  of 
signals  that  appear  on  the  data  bus.  The  zero  crossing  deviations  allowed 
are  not  well  defined  for  all  possible  patterns,  and  the  rise  and  fall  time 
specification  is  open  ended.  The  waveform  characteristics  defined  in  1553B 
provides  control  of  the  zero  crossing  deviations  for  all  possible  conditions 
and  establishes  a  limit  on  distortion.  Ail  systems  except  the  F-18 
specify  a  rise/fall  time  which  defines  a  trapezoidal  waveform.  The  F-18 
specification  (MDC  A3818)  specifies  a  heavily  filtered  waveform  which 
approximates  a  sine  wave.  It  should  be  noted  that  this  specification  applies 
to  the  output  waveform  of  the  terminal  only.  The  receiver  must  respond 
to  anything  from  a  square  wave  to  a  sine  wave  due  to  the  inherent  filtering 
characteristics  of  the  bus. 
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3.8.4 


Zero  Crossing  Deviation 


The  zero  crossing  deviation  requirement  of  1553B  is  broad  enough  to  cover 
all  systems  where  this  parameter  is  specified,  yet  more  clearly  defines  this 
requirement  for  all  waveforms, 

3.8.5  Clock  Stability 

The  long  and  short-term  clock  stability  requirement  is  identical  for  all  but 
1553B.  This  specification  was  relaxed  by  a  full  order  of  magnitude  in  1553B 
to  allow  for  the  selection  of  multiplex  bus  interface  clocks  that  can  meet  the 
long- shelf -life  requirements  of  some  weapon  systems. 

3.8.6  Output  Noise 

The  MIL-STD- 1553A  specified  value  of  10  mV  p-p  noise  is  considered 
unrealistically  low  for  practical  hardware  design.  Also,  noise  is  normally 
specified  as  an  rms  value  since  peak  noise  is  difficult  to  measure.  The  out¬ 
put  rms  noise  for  the  transformer -coupled  and  direct- coupled  cases  are 
specified  in  1553B  and  are  consistent  with  the  required  system  performance 
and  practical  terminal  hardware  design.  The  requirement  for  low  output 
noise  of  14  mV  rms  and  5  mV  rms  when  not  transmitting  also  places  signifi¬ 
cant  constraints  on  the  length  and  routing  of  input- output  wiring  because  of 
the  induced  power  supply  and  logic  noise  generated  in  the  terminal.  Note  that 
the  output  noise  limit  is  generally  dependent  on  the  output  signal  level,  with 
higher  output  levels  being  more  tolerant  of  noise. 

3.8 . 7  Common  Mode  Rejection 

The  common  mode  rejection  specifications  are  generally  compatible,  all 
being  in  compliance  with  MIL-STD-  1553B. 
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4.0 


S ELECTION  OF  TECHNIQ UES 


The  results  of  the  feasibility  study  were  used  to  assess  Dossible  techniques  to 
be  used  in  achieving  bus  compatibility.  In  this  task  data  accumulated  and 
analyzed  during  the  other  tasks  was  brought  together  for  the  achievement 
final  goal  of  the  study.  The  rationale  for  technique  selection  draws  heavily  on 
the  past  history  of  data  buses,  experience  in  the  design  and  development  of 
data  bus  products  and  information  gained  through  active  participation  in 
industry  forums  such  as  NAECON,  SAE-A2K  and  the  AFSC  Data  Bus 
Conferences. 

This  section  describes  areas  of  incompatibility  and  techniques  recommended 
to  achieve  the  desired  degree  of  bus  interface  commonality. 

4.  1  BACKGROUND  AND  RATIONALE 

Selection  of  the  most  suitable  technique  for  multiplex  hardware  compatibility 
involves  tradeoffs  in  a  number  of  areas.  Some  of  the  major  areas  which 
were  considered  are: 

e  Ease  of  Retrofit 

e  Future  Implementation 

e  Software  Impact 

*  Life  Cycle  Cost 

4.  1.  1  Ease  of  Retrofit 

One  object  of  the  study  effort  was  to  determine  the  feasibility  of  utilizing  a 
piece  of  avionics  hardware  in  a  multiplex  system  which  it  may  not  have  been 
designed  to  interface  with.  This  may  involve  installing  new  equipment  in  an 
existing  aircraft  (retrofit)  or  incorporating  existing  hardware  into  a  new 
system  design.  In  either  case,  the  problem  is  similar:  Determine  the  most 
effective  method  for  achieving  a  compatible  interface.  Considerations  involve 
not  only  technical  impact  (i.  e. ,  what  method  has  the  least  effect  on  satisfactory 
operation  of  the  modified  hardware),  but  also  cost  impact. 


Cost  impact  involves  not  only  initial  cost  of  retrofit,  but  also  (and  sometimes 
more  importantly)  reliability  and  ease  of  maintenance,  which  affect  overall 
life  cycle  cost. 


4.1.2  Future  Implementation 

A  perhaps  more  far-reaching  impact  of  the  chosen  technique  is  the  ease  with 
which  it  lends  itself  to  incorporation  in  future  MUX  systems.  In  order  to 
evaluate  this  factor,  considerable  insight  is  required  into  the  present  trends 
in  avionics  architecture  and  multiplex  standardization.  For  example,  should 
primary  emphasis  be  placed  on  a  DAlS-type  system  approach  or  will  the 
present  trend  toward  distributed  systems  architecture  (distributed  processing) 
persist  far  into  the  future?  Does  1553B  represent  a  stable  standard  or  will 
future  perturbations  in  the  standard  have  an  adverse  effect  on  todays  concept 
of  standardized  hardware,  i.  e. ,  how  much  flexibility  should  be  built  into  new 
hardware  to  allow  for  possible  future  changes  in  the  standard?  The  trend 
toward  1553  compatibility  in  commercial  standards  such  as  ARINC  453  is  also 
a  consideration. 

4.1.3  Software  Impact 

A  consideration  which  has  been  often  been  de- emphasized  or  even  overlooked 
is  that  of  software.  The  present  explosion  of  digital  technology  has  brought 
with  it  an  infatuation  with  the  seeming  flexibility  of  software.  In  practice 
hew  ever,  the  cost  associated  with  software  documentation  can  be  enormous. 
The  problem  of  software  impact  must  therefore  play  a  significant  role  in  the 
selection  of  any  technique. 

4.1.4  Life  Cycle  Cost 

The  initial  acquisition  cost  of  any  equipment  can  be  deceptive  if  the  equipment 
is  expected  to  be  used  over  a  period  of  many  years.  A  much  more  meaningful 
figure  is  that  of  cost  of  ownership  or  life  cycle  cost  (LCC).  Life  cycle  cost 
involves  all  expenses  associated  with  a  given  piece  of  hardware  and  involves 


such  factors  as  reliability,  expected  service  life,  maintenance  cost,  spares 
and  even  such  indirect  factors  as  shipping,  handling  and  storage  costs 
(especially  as  related  to  spares).  Maintenance  of  documentation  also  figures 
prominently  in  LCC  and  this  is  especially  true  of  software.  Although  LCC 
is  a  necessary  and  extremely  important  consideration,  its  realistic  assessment 
is  not  an  easy  task.  Every  effort  was  made  to  develop  a  realistic  and  practical 
assessment  of  LCC  impact. 

4.2  USE  OF  THE  BROADCAST  OPTION 

The  broadcast  definition  was  added  to  1553B  to  describe  a  new  protocol  option. 

The  use  of  this  protocol  allows  a  bus  controller  or  a  remote  terminal  to  address 
more  than  one  terminal  at  a  time  connected  to  the  system.  This  is  accomplished  by 
transmitting  a  dedicated  terminal  address  (11111)  and  each  receiver  with¬ 
holding  the  normal  status  word  response.  None  of  the  candidate  systems 
utilize  the  broadcast  option,  although  it  is  a  requirement  of  the  F-16  data  bus 
specification  (16PP188).  Therefore,  although  all  F-16  data  bus  hardware 
includes  the  broadcast  capability,  it  has  hever  been  used  in  production  service. 

In  fact,  Notice  1  to  MIL-STD- 1553B  specifically  disallows  the  broadcast 
option  for  Air  Force  use.  Note  that  the  F-16  requires  broadcast  only  for  mode 
codes  and  not  data  transfers --the  T/R  bit  and  subaddress  fields  are  not  decoded. 

4.2.1  Broadcast  Operation 

The  broadcast  mode  provides  a  means  for  transmitting  information  to 
multiple  users  with  a  single  message.  The  mechanism  for  accomplishing  this 
is  to  dedicate  address  31  (11111)  to  be  reserved  for  broadcast  messages. 

Anytime  a  broadcast  message  is  transmitted,  the  transmitting  terminal  will 
use  address  31  rather  than  a  unique  terminal  address.  All  other  addresses 
can  be  assigned  as  in  1553A.  Since  multiple  users  receive  a  broadcast 
message,  the  responding  status  word  must  be  suppressed.  By  choosing  the 
terminal  address  method  to  accomplish  the  broadcast  mode,  all  the  other 
formats  of  the  command  word  are  available  for  use.  Broadcast  messages  can 
be  used  with  subaddresses  and  mode  codes.  The  subaddress  in  a  broadcast 
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message  can  allow  multiple  users  with  broadcast  reception  capability  to  sort  out 
specific  broadcast  messages  transmitted,  if  given  this  capability  in  hardware 
or  software.  Therefore,  multiple  sets  of  broadcast  messages  can  be  defined. 

In  addition,  the  broadcast  format  can  be  used  with  mode  commands.  This  allows 

•A**— 

simultaneous  transmission  of  mode  codes  to  users. 

Indiscriminate  use  of  the  broadcast  technique  is  not  advisable.  Designers 
must  question  the  benefit  of  discarding  the  command -response  format,  in 
which  all  message  completion  failures  are  known  to  the  bus  controller,  to 
the  benefits  described  below.  Broadcast  use  may  increase  system  operation 
complexity  since  subaddresses  of  broadcast  address  and  addressed  terminal 
will  not  likely  be  the  same.  This  requires  additional  subaddresses.  Finally, 
the  broadcast  technique,  if  used,  adds  a  failure  mode  to  the  system  If  a 
terminal  in  a  failed  state  uses  address  31  for  a  message. 

Proper  use  of  the  broadcast  mode  may  yield  several  benefits: 

e  Multiple  terminals  can  be  communicated  with  simultaneously,  thereby 
permitting  time  synchronization  of  data  or  commands. 

•  Bus  duty  cycle  can  be  reduced  by  transmitting  data  required  by  multiple 
users  simultaneously  instead  of  sequentially, 
e  Some  error  management  can  be  enhanced  by  providing  a  single  address 
by  which  all  terminals  can  receive  commands  simultaneously.  This 
permits  the  bus  controller  to  immediately  command  a  state  for  the 
system,  e.  g.  reset,  rather  than  polling  each  unit  individually  with  the 
same  command  in  a  serial  fashion. 

The  broadcast  message  capability  can  produce  considerable  reduction  in  bus 
usage.  This  is  particularly  true  for  systems  using  multiple  units  for 
redundancy  or  systems  dependent  on  parallel  processing,  thus  requiring 
simultaneous  data  arrival  at  the  processing  units.  As  noted  in  1553B,  improper 
use  of  the  broadcast  format  can  result  in  undesirable  system  operation. 

Since  no  status  word  response  is  allowed  from  the  receiving  terminal. 
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discretion  mast  be  exercised  when  applying  the  capability.  To  provide 
message  arrival  verification,  a  bit  in  the  status  word  is  set  when  a  valid 
broadcast  message  is  received.  This  allows  reporting  of  the  reception  if 
requested  by  the  active  bus  controller  using  the  mode  code  "transmit  status 
word".  In  error  situations,  it  may  be  advisable  for  the  bus  controller  to 
request  the  last  command  word  to  verify  that  the  broadcast  command  was 
received.  There  may  be  situations  for  which  rebroadcast  cannot  be  permitted. 
Asking  for  last  command  first  preserves  the  last  status  word  (i.  e. ,  the 
terminal  does  not  reset  or  update  status).  In  addition  to  data  transfers,  the 
ability  to  transmit  a  broadcast  command  message  provides  an  effective 
method  for  managing  the  data  bus  system.  This  capability  is  performed 
using  the  broadcast  address  in  combination  with  mode  commands. 

4.2.2  Implementation 

The  broadcast  mode  itself  is  relatively  easy  to  implement,  requiring  a 
minimum  of  hardware  for  status  word  suppression  and  multiple  address 
recognition.  Indeed,  this  is  essentially  all  that  Is  necessary  in  the  controller- 
to-RTs  broadcast  case.  The  logic  becomes  a  bit  more  difficult  in  the  RT-to- 
RTs  broadcast  mode,  however.  RT-to-RT  operation  in  itself  is  unique  in  that 
It  is  the  only  case  where  an  RT  must  recognize  two  consecutive  command 
words  on  the  bus  before  a  data  transaction  takes  place.  In  an  RT  A  to  RT  B 
transaction,  for  example,  RT  B  receives  a  receive  command  followed 
immediately  by  a  transmit  command  to  RT  A.  RT  B,  however,  must 
effectively  ignore  the  command  to  RT  A  and  remain  prepared  to  receive  data 
on  a  delayed  basis.  This  can  be  a  problem  in  RT  to  RTs  broadcast  mode, 
since  the  broadcast  command  puts  all  RTs  in  receive  mode  and  the  next 
command  is  a  command  to  transmit  directed  to  one  of  these  RTs.  This 
means  that  all  RTs  must  receive  and  decode  the  terminal  address  of  the 
second  command  yet  remain  in  the  receive  mode  if  the  transmit  command 
was  not  directed  to  them.  The  one  receiving  the  transmit  command  must 
override  the  previous  receive  command.  This  complicates  the  RT  logic 
somewhat  if  the  RT  to  RTs  bro  .  least  option  is  to  be  implemented. 
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4.2.3  Effects  on  Interface  Compatibility 

Several  potential  problems  exist  if  broadcast  and  non-broadcast  equipped 
hardware  is  intermixed.  Some  of  the  various  combinations  and  effects  are 
as  follows. 

Broadcast  Implemented  in  all  hardware,  but  not  used.  This 
presents  no  problem  as  long  as  address  31  (11111)  is  avoided.  Assignment  of 
address  31  to  an  RT  would  result  in  no  response  since  the  RT  would  interpret 
the  all  ones  address  as  a  broadcast  command. 

Broadcast  Implemented  in  bus  controller  but  not  in  RT.  Non- 
broadcast  RT  would  not  recognise  broadcast  message,  but  would  respond 
with  status  if  set  to  address  31. 

Broadcast  implemented  in  RT  but  not  in  bus  controller.  RT 
would  not  respond  to  address  31.  O. K.  if  address  31  is  avoided. 

4.2.4  R  ecommendations 

Two  possibilities  exist  for  implementing  broadcast  compatibility  in  a  multi¬ 
plex  interface:  (1)  an  interface  which  is  programmable  for  broadcast  or 
non-broadcast  operation.  This  would  allow  address  31  to  be  used  in  a  non¬ 
broadcast  system.  (2)  Implement  broadcast  capability  in  all  hardware  and 
leave  its  use  to  the  system  integrator.  Address  31  would  not  be  used  if 
broadcast  were  not  implemented. 
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The  latter  method  (2)  is  preferred  since  it  would  not  require  a  special 
programming  feature  in  the  hardware  and  it  would  operate  in  full  compliance 
with  MIL-STD- 1553B  which  requires  that  address  31  be  reserved  for  broad¬ 
cast. 

4.  3  RESPONSE  TIME 

An  aspect  of  message  timing  which  has  caused  some  degree  of  system 
compatibility  problems  is  specified  response  time.  For  purposes  of  this 
discussion  response  time  involves  transmitter  time-out  and  no-response 
time-out  times  as  implemented  in  the  bus  controller  and  RTs. 

As  discussed  in  Section  3.  6.  1,  the  response  time  of  2  to  5  usee  which  is 
normally  allowed  was  increased  by  100%  by  1553B.  This  relaxing  of  the 
response  time  allows  more  flexibility  in  the  design  of  multiplex  interface 
hardware.  This  is  especially  true  where  the  interface  is  with  a  heavily 
loaded  microprocessor  which  may  not  have  sufficient  time  to  format  the 
status  word  within  the  allotted  response  time.  This  poses  no  problem  with 
new  designs  which  incorporate  the  new  no-response  time-out  requirement 
(not  previously  specified)  of  1553B. 

4.  3.  1  Effects  on  Interface  Compatibility 

MIL-STD- 1553B  specifies  that  the  bus  controller  wait  a  minimum  of  14  usee 
for  an  RT  to  respond  before  declaring  a  no-response  condition.  This  poses 
a  compatibility  problem  for  a  MIL-STD- 1 553B  RT  operating  with  a  MIL-STD- 
1553A  controller  such  as  the  AN/AYK-14  SIM  (Serial  Interface  Module)  which 
times  out  in  7  usee.  This  means  that  a  1S53B  RT  which  may  wait  14  usee 
before  responding  could  be  declared  faulty  by  the  bus  controller  which  times 
out  in  7  usee.  This  has  in  fact  proved  to  be  a  problem  with  a  system  which 
specified  1553B  RTs  but  was  obligated  to  use  the  AN/AYK-14.  Note  that 
this  is  the  only  situation  where  a  time-out  compatibility  problem  can  exist. 

A  1553B  controller  will  be  compatible  with  either  1553A  or  1553B  RTs. 
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4.  3.  2 


Recommendations 


Interface  compatibility  in  this  case  involves  two  areas:  (1)  the  response 
time  of  the  RT  and  (2)  the  no-response  time-out  of  the  bus  controller. 

4.  3.  2.  1  No-Response  Time-Out 

Since  the  longer  time-out  of  14  usee  is  compatible  with  any  RT,  it  is 
recommended  that  all  bus  controllers  incorporate  this  time-out  in  accordance 
with  1553B, 

4.  3.  2.  2  Response  Time 

The  choice  of  a  preferred  response  time  is  a  bit  more  involved.  Although 
the  short  response  time  of  2-5  usee  would  be  compatible  with  most  bus 
controllers,  this  would  negate  the  advantages  of  the  longer  time  allowed  by 
1553B.  Use  of  the  longer  time  of  4-12  usee,  however,  poses  problems  with 
1553A  controllers  as  discussed  previously. 

Therefore,  it  is  recommended  that  a  selectable  response  time  be  incorporated 
in  the  RT  to  allow  selection  of  either  a  short  or  long  response  time. 

4.  4  MODE  CODES 

MIL-STD-1 553B  defines  an  optional  mode  control  feature.  For  RTs 
exercising  this  option,  a  subaddress /mode  code  of  00000  or  11111  implies 
that  the  contents  of  the  word  count  field  are  to  be  decoded  as  a  five-bit  mode 
code,  A  mode  code  may  or  may  not  require  the  transmission  or  reception  of  a 
single  data  word.  The  RT  with  optional  mode  control  capability  must 
be  able  to  decode  the  word  count/mode  code  field  for  the  proper  number 
of  data  words  (0  or  1)  and  set  the  word  counter  accordingly.  In  this  case 
the  word  count  can  only  be  0  or  1  as  signified  by  the  most  significant  bit 
(bit  time  15)  of  the  mode  control  field.  This  feature  simplifies  the  decoding 
circuitry  by  allowing  this  bit  to  be  used  to  set  the  word  counter  when  a  mode 
command  is  received. 
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4.  4.  1 


Mode  Command  Recognition 

The  first  compatibility  problem  encountered  is  recognition  of  the  mode 
command  itself.  Since  some  existing  systems  use  all  l's  in  the  subaddress 
field  and  some  use  all  0's  to  indicate  a  mode  command,  hardware  designed  for 
these  two  types  of  systems  is  generally  not  interchangeable.  Since  1553B  reserves 

both  codes,  this  problem  is  easily  overcome  by  requiring  that  the  terminal 
recognize  both  codes  and  reset  the  word  counter  accordingly  based  on  the 
most  significant  bit  of  theword  count/ mode  code  field.  If  the  instrumentation 

bit  option  is  used,  of  course,  the  mode  command  will  be  restricted  to  all  l's. 

See  Paragraph  3.  5.  2  for  a  description  of  the  use  of  the  instrumentation  bit. 


4.  4.  2  Mode  Code  Decoding 

Mode  codes  can  be  divided  into  two  main  categories:  (1)  those  which  are 
transferred  to  the  using  subsystem  for  action  and  (2)  those  which  are  acted 
on  by  the  RT  itself  independently  of  the  user. 

An  example  of  a  mode  code  which  requires  user  response  would  be 
dynamic  bus  control  (00000)  which  requires  the  setting  of  an  acceptance  bit 
in  the  status  word.  Mode  codes  such  as  transmit  status  or  transmitter 
shutdown,  on  the  other  hand,  can  be  performed  directly  by  the  remote 
terminal  without  input  from  the  user. 

It  is  conceivable  that  a  simple  bus  interface  may  not  include  mode  decoding 
at  all  but  only  recognize  the  mode  command  and  simply  transfer  the  word 
count/mode  code  field  to  the  user  for  decoding.  Most  processors,  however, 
lack  sufficient  speed  to  decode  the  mode  code  field  and  return  the  proper  response 
to  the  interface  within  the  allotted  response  time  of  12  usee.  Therefore, 
this  method  is  not  recommended  except  in  special  cases.  A  general  purpose 
interface  must  be  able  to  handle  mode  code  field  decoding  in  order  to  preclude 
the  possibility  of  timing  problems. 
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4.4.  2.  1  User  Interface  Techniques 

Several  techniques  are  available  for  transferring  the  mode  code  field  to  the 
user.  Some  of  these  are: 

•  Dedicated  lines 

•  Parallel  binary  code 

•  Data  lines 

The  use  of  dedicated  lines  is  the  most  direct  but  perhaps  the  most  complex 
method.  With  this  technique,  the  RT  interface  would  decode  the  mode  code, 
perform  the  necessary  action  and  transfer  a  flag  to  the  user  on  a 
dedicated  control  line.  This  would  require  a  total  of  32  dedicated  lines 
between  the  interface  and  the  user  to  accommodate  the  full  five-bit  mode 
code  field  including  reserved  codes.  A  programmable  interface  could  be 
designed  to  accommodate  a  limited  number  of  codes  which  could  be  selected 
by  the  user,  thereby  reducing  the  number  of  interface  lines. 

The  use  of  a  parallel  binary  code  would  be  essentially  the  same  as  transferring 
the  five-bit  mode  code  field  directly  to  the  user.  The  RT  interface,  however, 
would  still  decode  the  field  and  take  the  necessary  action  independently  of 
the  user  decoding.  This  would  decrease  response  time  but  would  mean  that 
the  decoding  must  be  done  twice,  once  in  the  interface  and  once  in  the  user. 

The  third  method  involves  the  use  of  the  16  parallel  data  lines  to  transfer  the 
mode  code  data.  Decoding  would  be  the  same  as  for  dedicated  lines  except 
that  use  of  the  data  lines  would  eliminate  me  need  for  the  32  additional 
interface  lines.  This  method  would  allow  16  mode  codes  to  be  transferred 
simultaneously  on  the  data  line.  All  32  codes  could  be  transferred  in  two 
words. 
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4.  4.  2.  2  Mode  Code  Programming  Techniques 

The  actual  mode  codes  contained  in  the  word  count  field  vary  among  the 
six  systems  as  discussed  in  Section  3»4  and  tabulated  in  Table  5. 

A  flexible  RT  interface  must  provide  the  means  of  accommodating  the 
different  mode  code  assignments  for  different  systems.  This  problem  is 
of  little  significance  if  the  mode  decoding  is  left  to  the  user.  In  keeping 
with  the  recommendation  of  the  preceding  section,  however,  the  RT  must 
be  capable  of  decoding  the  mode  code  field  independently  of  the  user  and 
therefore  must  have  a  means  of  programming  to  accommodate  the  various 
mode  code  definitions.  Assuming  that  the  mode  codes  are  software  (or 
firmware)  controlled,  the  programming  could  be  handled  by  two  basic 
methods: 

•  External  Programming  Pins 

•  Interchangeable  PROMs 

The  first  method,  the  use  of  external  programming  pins,  would  contain 
mode  code  definitions  for  a  number  of  different  systems  within  the  RT  and 
select  the  appropriate  set  by  means  of  applying  logic  levels  or  ground  straps 
to  a  set  of  external  code  pins.  The  number  of  pins  required  would  depend 
on  the  number  of  system  programs  contained  within  the  RT.  The  six 
candidate  systems,  for  example,  could  be  programmed  with  three  binary- 
coded  pins,  leaving  two  spare  codes. 

The  second  method,  the  use  of  interchangeable  PROMs  would  only  contain 
one  code  in  an  easily  replaceable  PROM.  This  method  would  be  slightly 
more  economical  in  that  only  the  code  in  use  need  be  contained  within  the  RT. 
This  slight  cost  advantage,  however,  may  be  offset  by  the  logistics  necessary 
to  maintain  separate  inventories  and  part  numbers  for  different  interfaces 
which  would  no  longer  be  directly  interchangeable. 
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Perhaps  the  most  practical  implementation  method  for  the  present  would 

9 

be  a  combination  of  the  two  approaches.  This  could  be  accomplished  by 
including  PROMs  within  the  RT  for  a  selected  number  of  existing  systems 
plus  a  number  of  spares  to  allow  programming  for  future  requirements. 

Such  a  unit  would  be  pin-programmable  as  in  the  first  method  to  meet 
retrofit  requirements,  but  would  also  provide  the  flexibility  of  the  second 
method. 

4.  4.  3  Recommendations 

Based  on  the  preceding  rationale,  it  is  recommended  that  mode  command 
recognition  be  incorporated  in  all  terminals  to  recognize  either  an  all  l's 
or  all  0's  mode  command  without  switching  or  programming. 

It  is  further  recommended  that  all  mode  codes  be  decoded  and  transferred  to 
the  user  on  the  parallel  data  lines. 

The  recommended  mode  code  programming  technique  is  to  incorporate  a 
selected  number  of  pin*  programmable  codes  within  the  RT  and  to  provide 
spare  PROMs  for  future  growth. 

4.  5  STATUS  WORD 

Since  MIL-STD- 1 553A  assigned  only  the  message  error  and  terminal  flag 
bits  in  the  status  word,  status  word  code  assignments  vary  widely  among 
the  six  systems.  Thus  a  means  must  be  provided  to  accommodate  the 
various  status  word  formats  for  the  different  systems. 

4.  5.  1  External  User  Interface 

As  in  the  case  of  the  mode  codes,  the  status  word  bits  can  be  divided  into 
two  major  categories:  (1)  those  which  require  inputs  from  the  using  sub¬ 
system  and  (2)  those  which  are  set  by  the  RT  itself  independently  of  the 
user.  All  bits  in  the  first  category  require  external  user  access  to  the 
status  buffer.  The  bits  requiring  external  access  will  of  course  vary  with 


the  different  systems.  As  an  example,  the  bit  assignments  and  external 
interface  requirements  for  a  MIL-STD-1553B  system  are  shown  in  Table 
10. 

As  was  noted  in  Section  3.  5,  the  only  bits  common  to  all  systems  are  message 
error  and  terminal  flag  (bit  times  9  and  19).  It  is  therefore  conceivable 
that  nine  of  the  status  bits  (10  through  18)  may  require  external  access  to  the 
status  register  in  one  or  more  of  the  systems.  For  this  reason,  a  flexible 
remote  terminal  interface  should  include  an  external  interface  to  these  nine 
bits  of  the  status  register  as  a  minimum. 

4.  5.  2  Status  Transmission 

As  noted  previously,  the  RT  must  respond  with  a  status  word  within  2  to  12 
usee  (depending  on  system  specification)  after  a  command  word  is  received. 
This  means  that  any  status  response  required  from  the  user  must  be  loaded 
into  the  status  register  within  this  time  period..  Two  methods  are  available 
for  accomplishing  this: 

•  User  loads  register  asynchronously  and  RT  transmits  contents  after 
specified  delay. 

•  User  initiates  status  response 

The  first  method  places  the  full  responsibility  of  status  transmission  on  the 
RT.  with  the  user  responsible  for  ensuring  that  the  status  register  has  been 
loaded  within  the  allotted  time.  If  a  status  bit  has  not  been  loaded,  the  RT 
will  transmit  the  contents  of  the  register  anyway  resulting  in  a  possible 
incorrect  status  transmission. 

With  the  second  method,  the  RT  raises  a  "status  request"  line  when  a  command 
is  received.  The  user  senses  the  status  request  line,  loads  the  status 
register  and  raises  a  "transmit  status"  line  which  initiates  the  status  word 
transmission.  Note  that  with  this  technique,  the  status  word  transmission 
is  under  complete  control  of  the  user.  If  the  user  does  not  send  the  "transmit 


Table  10 


Status  Buffer  Interface 

INTERFACE  REQUIRED 


BIT  TIME 

FUNCTION 

INTERNAL 

EXTERNAL 

9 

MESSAGE  ERROR 

X 

10 

INSTRUMENTATION 

X 

11 

SERVICE  REQUEST 

X 

12 

RESERVED 

X 

°r  _ 

X 

13 

RESERVED 

X 

_ or  _ 

X 

14 

RESERVED 

X 

or 

X 

15 

BROADCAST  CMD.  RCVD. 

X 

16 

BUSY 

X 

17 

SUBSYSTEM  FLAG 

X 

18 

DYNAMIC  BUS  CONT. 

ACCEPTANCE 

X 

19 

TERMINAL  FLAG 

X 

i 
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status"  signal  within  the  allotted  time,  a  no-response  condition  will  exist. 

This  technique  would  also  delegate  response  time  control  to  the  user  and  so 
eliminate  the  need  to  program  the  RT  response  time.  While  this  method  has 
some  merit  by  virtue  of  the  flexibility  in  response  time,  it  places  an 
unncessary  burden  on  the  user.  Further,  it  would  appear  from  examination 
of  Table  10  that  asynchronous  loading  is  adequate  for  most,  if  not  all,  of 
the  status  response  bits.  Of  the  bits  requiring  external  inputs,  the 
instrumentation  bit  is  always  zero,  (except  for  the  B-52  OAS,  which  indicates 
a  designated  subsystem  failure  by  setting  bit  10),  and  the  service  request  bit  is 
preset  before  a  command  word  is  received,  as  is  the  subsystem  flag.  Only  the 
Dynamic  Bus  Control  acceptance  bit  need  be  set  in  direct  response  to  a  re¬ 
ceived  command.  Even  here,  it  would  be  possible  for  the  RT  to  set  this 
bit  based  on  a  preset  condition  of  a  user  buffer. 

4.  5.  3  Status  Bit  Programming 

The  problem  of  defining  the  status  bit  assignments  is  essentially  the  same 
as  that  of  the  mode  codes,  so  the  same  two  basic  methods  apply: 

•  External  Programming  Pins 

•  Interchangeable  PROMs 

Here  again,  the  first  method  would  make  use  of  a  number  of  pre-programmed 
systems,  all  contained  within  the  RT  and  selected  by  the  means  of  external 
code  pins.  The  second  technique  would  contain  the  status  bit  program  in  an 
easily  replaceable  PROM. 

4.  5.  4  Recommendations 

Based  on  the  previous  discussion,  it  is  recommended  that  the  status  word  be 
implemented  as  follows: 

•  Status  register  bits  10  through  18  are  available  for  external  loading. 

•  The  status  register  is  loaded  asynchronously  by  the  user;  the  RT 
controls  status  transmission. 
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Status  bit  assignment  is  controlled  by  pin-selection  of  one  of  several 
PROMs,  with  spares  provided  for  growth. 


4.  6  TRANSMITTED  WAVEFORM 

Of  the  basic  signal  characteristics  discussed  and  tabulated  in  Section  3.  8, 
perhaps  the  most  difficult  for  the  designer  to  accommodate  is  that  of  the 
transmitted  waveform.  Although  all  receivers  must  be  designed  to  detect  a 
sine  wave,  the  transmitter  output  specifications  vary  from  a  trapezoidal 
waveform  to  a  sine  wave.  All  six  systems  have  different  output  wave¬ 
form  rise/fall  time  characteristics  as  shown  in  Table  11. 

4.  6.  1  Sine  Wave  Vs.  Trapezoidal 

A  significant  debate  has  developed  over  the  most  desirable  waveform 
characteristics  for  the  transmitted  data  bus  signal.  The  1553A  standard 
limits  the  rise  and  fall  time  to  no  less  than  100  ns  and  1553B  specifies  a 
range  from  100  to  300  ns.  The  F -18  specification  has  defined  a  limit  on 
the  harmonic  content  of  the  output  to  essentially  restrict  the  waveform  to  a 
sine  wave.  This  is  in  contrast  to  the  other  systems  which  permit  a  trapezoidal 
waveform  with  limited  rise  and  fall  times  ajnd  limited  droop.  The  trans¬ 
mission  of  a  sine  wave  on  the  bus  requires  extensive  filtering  and  imple¬ 
mentation  of  a  linear  driver  resulting  in  increased  complexity  and  cost  and 
a  significant  increase  in  output  driver  power  dissipation. 

It  has  also  been  found  that  a  practical  filter  implementation  that  allows  the 
specified  rolloff  characteristics  results  in  an  overshoot  larger  than  that 
specified  by  1553B. 

Additionally,  the  transmitter  efficiency  is  reduced,  resulting  in  increased 
dissipation  for  the  same  delivered  power.  The  rationale  developed  to  justify 
this  approach  is  as  follows: 
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Table  11 


Waveform  Characteristics 


SYSTEM 
MIL -STD- 1 553  B 
MIL-STD-1 553A 
F-  16 

B- 52  OAS 
F- 18 
YAH- 64 


WAVEFORM  RISE/ FALL  TIME  (ns) 
100-300 
100 

40-200 
100-130 
Sine  Wave 
(Data  not  available) 


I 
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1.  The  radiated  harmonics  of  the  unfiltered  trapezoid  can  interfere  with 
other  equipment  on  the  aircraft. 

2.  The  mismatch  inherent  in  the  data  bus  network  caused  by  nonideal 
terminations,  stubbing  and  cable  characteristics  results  in  complex 
reflections  because  of  the  harmonic  content  of  the  unfiltered  waveform. 

EMI  testing  has  been  performed  to  measure  the  radiated  interference  from  a 
twisted- shielded  pair  with  15V  p-p  into  50  ohms.  The  test  was  conducted  in 
a  shielded  room,  with  the  test  cable  penetrating  the  wall  of  the  screen  room 
and  the  shield  grounded  at  the  point  of  penetration.  The  1553  waveform 
generator  was  located  outside  the  screen  room.  Measurement  techniques 
were  in  accordance  with  the  procedures  set  forth  in  MIL-I-6181D.  With  a 
balanced  drive  and  care  taken  to  ensure  that  no  significant  common  mode 
signal  was  impressed  on  the  line,  the  interference  level  could  not  be 
detected  above  the  receiver  ambient  noise  level. 

It  is  known  by  those  familiar  with  1553  data  bus  systems  that  the  twisted 
pair  shielded  cable  is  essentially  a  distributed  low-pass  filter  and  the 
problem  of  item  2  is  significantly  reduced  because  a  few  feet  of  cable 
effectively  provides  a  filtering  effect. 

The  conclusion  is  that  special  filtering  at  the  transmitter  can  be  employed 
to  reduce  signal  distortion  and  emanations  from  the  bus  if  the  added  expense 
and  complexity  can  be  justified. 

4.  6.  2  Recommendations 

While  it  is  possible  to  design  a  transmitter  which  will  meet  essentially  all 
the  specifications  requiring  a  trapezoidal  waveform,  it  is  considerably 
more  difficult  to  meet  the  sine  wave  specification  as  well.  While  transmitters 
have  been  designed  which  closely  approximate  either  waveform  by  removing 
or  adding  filter  components,  designs  which  actually  meet  both  specifications 
have  been  largely  unsuccessful. 


For  these  reasons,  and  due  to  the  added  expense  o£  the  sine  wave  interface, 
it  is  recommended  that  the  sine  wave  option  not  be  included  as  part  of  a 
common  design.  Instead,  it  is  recommended  that  the  programmable  interface 
be  designed  with  interchangeable  transmitter  modules  which  will  allow  the 
RT  to  be  easily  changed  from  trapezoidal  to  sine  wave  by  simply  plugging  in 
the  appropriate  transmitter  module. 
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RECOMMENDED  IMPLEMENTATION 


5.  0 

This  section  describes  a  recommended  hardware/ software  implementation 
for  a  programmable  remote  terminal  module  employing  techniques  described 
in  the  preceding  section.  A  three-processor  concept  is  developed  to  achieve 
the  interface  between  two  MIL-STD- 1 553B  redundant  data  buses  and  a  computer 
subsystem  bidirectional  data/control  bus. 

5.  1  THREE  PROCESSOR  CONCEPT 

The  key  design  philosophy  for  the  development  of  the  Programmable  Interface 
Module  (PIM)  is  the  use  of  distributed  processing.  The  speed  and 
redundancy  requirements  of  the  PIM  concept  dictate  the  division  of  the 
interface  into  three  inter-dependent  modules:  two  Bus  Interface  Modules 
(BIMs)  and  a  Computer  Interface  Controller  (CIC).  The  BIMs  provide 
the  two  independent  real-time  interfaces  between  the  dual  redundant  MIL- 
STD-1553B  busses  and  the  internal  16  bit  PIM's  data/control  bus.  The  CIC 
controls  the  internal  16  bit  PIM's  data/ control  bus,  and  the  digital  interface 
to  the  user  subsystem.  The  three-processor  concept  allows  three  or  more 
independent  software/hardware  controlled  events  to  occur  simultaneously. 

The  PIM  concept  is  shown  in  block  diagram  form  in  Figures  14  and  15. 

5.  2  BUS  INTERFACE  MODULE 

The  two  BIM  modules  provide  the  receiver/ transmitter  interfaces  to  meet 
the  requirements  of  the  applicable  multiplex  data  bus.  Each  BIM  unit  is 
responsible  for  the  conversion  of  the  data  bus  signal  into  a  16-bit  parallel  data / 
control  bus  signal.  The  16  bit  parallel  data/ control  bus,  internal  to  the  BIM 
unit,  will  then  be  used  for  the  bidirectional  transfer  of  data  and  control  signals 
with  the  CIC. 
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Figure  14 
Block  Diagram 


Figure  15 

PIM  Detailed  Block  Diagram 


5.  2.  1  BIM  Functions 

The  BIM  provides  the  analog/digital  interface  to  the  data  bus,  a  Manchester 
encoder/decoder  for  NRZ/bi-phase  code  conversion  and  word  validation, 
command  word  and  message  format  recognition  and  validation,  status  word 
generation,  and  the  serial/parallel  conversions  for  interfacing  with  the  Cl C. 
Bus  message  processing  functions  are  provided  by  the  BIM  microprocessor, 
in  accordance  with  control  data  from  the  CIC  and  the  host  subsystem  for 
optional  message  formats  (broadcast,  mode  codes,  etc.  ). 

5.  2.  2  BIM  Analog  Interface 

The  BIM  Analog  transceiver  provides  transformer  coupling  to  the  data  bus 
with  the  transformer  turns  ratio  ieterming  the  signal  level  supplied  to  the 
bus.  The  wide  variations  in  specified  signal  amplitudes  require  a  different 
transceiver  module  for  each  of  the  defined  subsystems.  The  transceiver 
includes  a  coupling  transformer  of  the  proper  characteristics,  a  receiver 
set  to  the  desired  input  threshold  level,  and  a  transmitter  with  the  desired 
output  characteristics  for  the  particular  user  system. 

Since  it  is  anticipated  that  all  new  designs  will  incorporate  a  MIL.-STD-1553B 
interface,  it  is  this  interface  which  is  used  in  the  following  example: 

The  BIM  interface  to  the  MIL-STD- 1  553B  data  bus  provides  transformer 
coupling  for  short-stub  and  long-stub  bus  connections,  with  internal  strap 
options  for  the  following  stub  and  bus  shield  connections: 

1.  Short  stub  -  Resistor  isolated  connection  to  bus. 

2.  Long  stub  -  Direct  connection  to  bus  coupler  transformer. 

3.  Center  tap  on  bus  side  of  transformer  open. 

4.  Center  tap  on  bus  side  of  transformer  tied  to  bus  shield. 

The  module  strapping  for  the  two  stub  configurations  is  shown  in  Figure  16. 
The  multiple  bus  windings  of  the  transformer  provide  the  specified  receiver 
sensitivity  for  short  stub  (1.  2  Vp-p)  and  long  stub  (.  86  Vp-p)  configurations. 
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The  transmitter/ receiver  supplies  the  analog  circuitry  for  interfacing  the 
differential  data  bus  signals  with  the  internal  BIM  logic  levels.  The  receiver 
section  accepts  phase-modulated  bipolar  data  at  the  input  and  produces  a 
bi-phase  TTL  signal  at  the  output.  Signal  conditioning  is  provided  by  a  low- 
pass  filter  and  dual  level  detectors  for  positive  and  negative  excursions  of 
the  input  signal. 

The  transmitter  section  accepts  bi-phase  TTL  data  at  the  input  and  produces 
a  differential  output  signal  with  controlled  rise  and  fall  times  to  the  bus  coupling 
transformer.  It  is  recommended  that  the  transceiver  and  transformer  be  im¬ 
plemented  by  devices  similar  to  those  manufactured  by  ILC  Data  Device  Corp¬ 
oration.  The  transceiver,  part  number  DDC-8553,  is  available  in  a  24  pin 
hybrid  package  measuring  1.  4  x  0.  8  x  0.  2  inches.  The  bus  transformer,  part 
number  DDC-25679,  is  available  in  an  8  pin  module  measuring  0.  63  x  0.  63  x 
0.  275  inches. 

5.  2.  3  Data  Bus  Digital  Interface 

The  serial  bi-phase  interface  to  the  bus  transceiver  is  processed  by  a  Manchester 
encoder/decoder  (Harris  Corporation  part  number  HD- 15530/or  equivalent). 

The  decoder  section  samples  the  bi-phase  data  for  valid  sync  characters  and 
Manchester  data  bits,  and  outputs  serial  NRZ  data,  a  data  shift  clock,  sync 
polarity  identification,  and  a  valid  word  signal  to  indicate  the  successful  re¬ 
ception  of  a  word  without  any  Manchester  or  parity  errors.  The  data  is  shifted 
into  a  serial-to-parallel  register  for  terminal  address  recognition  and  interfacing 
to  the  BIM  processor. 

Transmit  data  is  loaded  into  a  parallel-to- serial  register  by  the  BIM  processor 
and  shifted  into  the  encoder  for  sync  character  generation  and  bi-phase  encoding. 
The  block  diagram  for  the  Data  Bus  Digital  Interface  is  shown  in  Figure  17. 

The  transmitter  timeout  logic  provides  the  independent  fail-safe  function  as 
specified  in  MIL-STD  - 1 553B. 


Figure  17 

Data  Bus  Digital  Interface 


5.  2.  4 


BIM  Processor 


The  BIM  processor  is  configured  as  a  microprogrammed  sequential  state  machina 
The  example  utilizes  the  Advanced  Micro  Devices  29116  microprocessor  and 
2910  microprogram  sequencer.  The  processor  contains  parallel  data/control 
ports  to  the  1553B  logic  interface  and  to  the  CIC.  The  firmware  for  the  two 
BIM s  will  be  identical,  but  since  the  BIMs  must  function  independently  with  the 
redundant  data  buses,  it  is  not  possible  to  share  the  same  PROMs  for  both 
modules.  The  BIMs1  PROMs  include  externally  strap  selectable  firmware  to 
accommodate  the  mode  code  and  status  bit  assignments  of  a  selected  number 
of  subsystems.  A  response  time  select  strap  is  also  provided  to  select  MIL- 
STD-1553  A/B  response  time.  All  strap  select  functions  are  coded  so  that 
MIL-STD-1553B  parameters  are  selected  when  no  straps  are  used. 

Data  bus  command  words  are  processed  serially  to  provide  subaddress  and 
word  count  information  to  the  CIC  and  the  host  subsystem  for  data  word 
buffer  access.  Status  Bits  10-18  may  be  externally  loaded  into  the  status  buffer 
by  the  host  via  the  data/ address  bus.  After  receiving  the  Terminal  Address, 

T/R  bit,  and  subaddress  fields  of  the  command  word,  a  service  request  is 
made  to  the  CIC  to  insure  that  the  host  data  word  buffer  may  be  accessed  in 
time  for  proper  response  to  transmit  commands.  In  the  case  of  invalid 
Command  words,  a  second  service  request  is  made,  and  a  flag  bit  is  set  to 
allow  the  CIC  to  abort  the  data  transfer.  All  message  transfers  are  buffered  in 
the  CIC' 8  RAM.  The  memory  map  for  the  RAM  is  shown  in  Figure  18, 

The  BIM's  firmware  contains  routines  for  built-in-test  (BIT)  and  data  path 
wraparound  tests  which  may  be  initiated  by  command  from  the  host  subsystem. 

5.  3  COMPUTER  INTERFACE  CONTROLLER 

The  CIC  is  responsible  for  all  data  and  control  transfers  between  the  BIMs 
and  the  host  subsystem  processor.  The  interface  utilizes  the  host  processors 
Programmed  I/O  (PIO),  Interrupt  (INT),  and  Direct  Memory  Access  (DMA) 
channels,  and  provides  the  initiation  and  response  to  all  handshake  signals. 
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RT  Status  Register 
Current  Command  Word 
Last  Command  Word 
Current  Status  Word 
Last  Status  Word 
TX  Data  Word  0 


36  TX  Data  Word  30 

37  TX  Data  Word  31 

38  RX  Data  Word  0 

39  RX  Data  Word  1 


69  RX  Data  Word  30 

70  RX  Data  Word  31 

71  RT  Mode  Code  Register  0 
RT  Mode  Code  Register  1 

102  RT  Mode  Code  Register  30 

103  RT  Mode  Code  Register  31 

104  Mode  Code  DataWord  TX 

105  Mode  Code  Data  Word  RX 

106  Vector  Word  Register 

107  BIT  Register 

108  RT  to  RT  Status  Register 

109  Command  Word  to  receiving  RT  from  RT  to  RT  Transfer 

110  Reserved  for  future  mode  codes 
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10110  to  11111 

Figure  18 
CIC  Memory  Map 
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5.  3.  1 


CIC  Functions 


The  number  of  existing  subsystem  processors  with  unique  interface  protocols 
make  a  universal  CIC  design  impractical.  The  initial  design  goal  should  be 
ifj  select  a  standard  processor  interface  such  as  the  Multi-Bus  or  Q-Bus  for 
development  of  the  PIM  concept. 

The  CIC/BIM  interface  is  essentially  independent  from  the  host  processor.  The 
CIC  arbitrates  the  use  of  the  internal  PIM  control/data  bus  and  access  to  the 
CIC's  RAM. 

5.  3.  2  CIC  Architecture 

The  CIC  will  utilize  the  same  processor  components  as  the  BIM  s.  The  CIC's 
RAM  is  implemented  as  a  dual-port  device  to  aLlow  concurrent  access  by  the 
BIMs  and  the  host  processor.  Data  transfers  between  the  MIL.-STD- 1 553B 
data  bus  and  the  host  processor  memory  are  buffered  in  the  RAM,  in  addition 
to  BIT,  Mode  Code,  and  Command  and  Status  Words  as  shown  in  Figure  18, 

Bus  data  words  are  transferred  to  the  host  processors  memory  via  the  DMA 
channel  to  minimize  the  host  software  overhead  requirements.  The  host 
processor  '•ill  be  required  to  have  data  buffer  pointers  available  for  all 
active  receive  and  transmit  subaddresses  and  all  mode  commands.  If  these 
pointers  are  stored  in  contiguous  memory  locations,  it  is  only  necessary  for 
the  hosl  to  supply  the  table  starting  address  to  the  PIM.  When  the  .  'IM 
receives  a  Command  word  from  the  bus,  the  CIC  uses  the  T/P  bit  and  the 
subaddress  field  as  a  vector  into  this  table.  Since  these  vector  ables  are  in 
the  host  processors  memory,  it  can  change  data  pointers  at  any  time. 

The  host  INT  channel  may  be  used  to  signal  the  completion  of  a  data  bus 
message  and  to  flag  the  results  ot  BIT  routines  in  the  PIM.  The  PIO  channel 
is  used  to  initialize  the  PIM  and  to  access  data  in  the  CIC's  RAM. 


